Message Queues: When and How to Stop Doing Work Inside HTTP Requests

There's a habit in early-stage backend development where everything happens inside a request handler. User signs up → create the record, send the welcome email, notify Slack, sync to the CRM, trigger the analytics event — all before the response goes back. This works until it doesn't. The response takes 3 seconds. One of those services goes down and the whole signup breaks. Traffic spikes and the queue of requests backs up. Message queues are the fix. Here's when to use them and how to actually set one up. The Mental Model An HTTP request is synchronous — the client waits for your response. A message queue decouples the work: the request handler publishes a message and responds immediately. A separate worker process picks up the message and does the actual work. Client → POST /signup → [Create user record] [Publish "user.created" message] ← takes milliseconds [Respond 201 Created] Background worker picks up "user.created" → [Send welcome email] [Notify Slack] [Sync to CRM] [Fire analyt