In this chapter
We'll learn what a service and a microservice are (a food court instead of one restaurant), what an API gateway does (the mall's front entrance), and how message queues and workers move slow jobs out of the way (an order rail in a kitchen) — and fix Friday's SMS problem.
The Problem in Real Life
Anna finds the slow part. After every successful booking, the checkout code sends an SMS confirmation before it answers the fan. The SMS company takes about 1.5 seconds per message. On Friday, 2,000 fans bought at once; every checkout sat waiting for its SMS, the server ran out of free workers to handle new requests, and new fans got 503s.
"The fan doesn't need to wait for the SMS," she says. "They just need to know they got the ticket." John grins. "Then let's give the SMS to someone else, and let checkout answer right away."
Never make a customer wait for work they don't need to watch.
John
Doing Everything While the Fan Waits vs. Handing Work Off
Slow jobs block fast ones
A 1.5-second SMS inside every checkout ties up the server while new fans queue.
Not everything must happen now
Emails, SMS and reports can happen a few seconds later without anyone noticing.
One program or many?
Some companies split big apps into many small services. That brings new benefits and new problems.
Services, Microservices, API Gateways, Queues and Workers
Service — a part that does one job for others: a service is a piece of software that does one job and offers it to other parts through an API (Act 12): a payments service, a notification service, a search service. Inside a monolith, a module can act like a service. When a service runs as its own separate program, it can be deployed, scaled and fixed on its own.
- Microservices — a food court instead of one big restaurant: in a microservice architecture, an application is split into many small, separately deployed services, each owning one business area and its own data — payments, bookings, notifications, search. Like a food court: many small stalls, each with its own kitchen and staff. If the noodle stall closes, the others keep serving. Each stall can hire more staff on its own when it's busy.
- The price of a food court: it's much harder to run. Every stall needs its own staff, deliveries and cleaning; customers walk between stalls; and if one stall's order depends on another's, things get complicated. In software: many deployments, network calls between services that can fail, data spread across many databases, and much harder debugging. That's why most companies start with a (modular) monolith and only split out services when they have a clear reason. The Microservices courses go deep into this.
- API gateway — the mall's front entrance: when there are many services, clients shouldn't have to know each one's address. An API gateway is one front door for all of them: every request comes in at the gateway, which checks the login, applies limits, and forwards the request to the right service — like a mall's main entrance with an information desk that points you to the right shop. It's a close cousin of the reverse proxy from Act 11.
- Message queue — the order rail in a kitchen: in a busy restaurant, the waiter doesn't stand by the stove waiting for each dish. They clip the order ticket onto a rail and go back to serve more guests; the cooks take tickets off the rail in order. A message queue is that rail for software: one part puts a message ("send an SMS to fan 12: your ticket for C14 is confirmed") into the queue and moves on immediately. The queue holds messages safely, in order (a queue from Act 09 — first in, first out), until someone picks them up.
- Worker — the cook who takes tickets off the rail: a worker is a background program whose only job is to take messages from a queue and do the slow work — send the SMS, send the email, generate a PDF ticket. It runs separately from the web server, so slow work never blocks a fan. Busy? Start more workers. A worker crashes? The message stays in the queue and another worker picks it up.
| Feature | Monolith (one restaurant) | Microservices (food court) |
|---|---|---|
| Deployed as | One program | Many small programs |
| One part fails | Can take everything down | Others keep working |
| Scaling | Scale the whole thing | Scale each service on its own |
| Running and debugging | Simple | Much harder: networks, many deployments |
| Best for | Most teams, especially early | Large teams and systems with clear reasons to split |
| Kitchen | Software |
|---|---|
| Waiter clips an order on the rail | App puts a message in the queue |
| Waiter goes back to serve guests | Server answers the fan right away |
| Order tickets wait on the rail, in order | Messages wait in the queue (first in, first out) |
| Cooks take tickets one at a time | Workers take messages and do the slow work |
| Busy night? Add another cook | Busy sale? Start more workers |
| Version | Fan waits | Server during a rush |
|---|---|---|
| Before: SMS sent inside checkout | ~1.5 seconds per booking | Tied up; new fans get 503 |
| After: SMS through a queue + worker | ~50 ms | Free to serve the next fan |
Checkout after the fix: the slow SMS moves to a queue
Fan clicks Pay
POST /api/bookings
App server saves the booking
transaction (Act 13)
Answers the fan: "You're booked!"
in ~50 ms
Puts "send SMS" in the queue
the order rail
SMS worker
takes messages off the queue, sends them a second later
The fix for Friday: Anna changes checkout. After the booking is saved (Act 13's transaction), the server puts an "send SMS" message into a queue and immediately answers the fan: "You're booked!" — in about 50 milliseconds instead of 1.5 seconds. A separate SMS worker takes messages from the queue and sends them, a second or two later. Fans don't notice the delay; the server is free to serve the next fan. The same goes for confirmation emails.
This is called asynchronous processing: doing work later, in the background, instead of making the requester wait for it (more in Act 23). It's one of the most powerful tools for handling sudden rushes — the queue simply gets longer for a minute, and the workers catch up.
Did BlueTicket need microservices? Anna asks. John's answer: "Not yet. We kept our modular monolith and added one queue and one worker. That fixed Friday. If one day notifications grow into a big system of their own, we might split them into a service — when there's a real reason."
Key Takeaway
A service does one job for other parts through an API; microservices split an app into many separately deployed services, like a food court — independent but much harder to run. An API gateway is the single front door that routes requests to services. A message queue is a kitchen's order rail: slow jobs are queued and the request answers immediately, while background workers take jobs off the queue — so slow work never blocks users.
Why This Matters
Queues and workers are one of the most common patterns in real systems — every "we've emailed your receipt," every video upload being processed, every order confirmation uses one. Knowing when work can happen later is often the cheapest way to make a system survive a rush. And knowing that microservices are a trade-off, not an upgrade, will save you from a lot of unnecessary complexity.
Checkout is fast again. But Anna redraws the diagram and notices something worse than slowness: there's still only one app server. However fast it is, there's a limit to how many fans one machine can serve — and if it dies, everything dies.