Message Queues

You're designing a notification system, and you tell the interviewer: "The API receives the request and sends the email directly through Twilio."

Seems reasonable. Then the follow-up hits: "What happens when Twilio is down for 30 seconds? What about when you need to send 5 million marketing emails at once? Do those block your login OTP codes?"

And now you realize that without a message queue, your system is fragile, tightly coupled, and can't handle real-world failure modes. Every production system that sends emails, processes images, or handles async work needs a queue somewhere.

Here's the mental model.

A producer (your API server) puts a message on the queue. A consumer (a worker process) picks it up and processes it. The queue is the buffer between them.

Think of it like a restaurant kitchen. The waiter takes your order (producer), clips the ticket to the rail (queue), and the cook picks it up when they're ready (consumer). The waiter doesn't stand there waiting for the food to be cooked. They go take more orders.

That's the key insight: the producer doesn't need to know or care what happens next. It drops a message on the queue and moves on. From the API's perspective, this is "fire and forget." You return a 202 Accepted and the work happens in the background.

API Server (Producer)
  ↓ drops message
Message Queue (Buffer)
  ↓ picks up when ready
Worker (Consumer)
  ↓ processes
External Service (Twilio, S3, etc.)

This decoupling is what makes your system resilient. If the worker crashes, messages wait in the queue. If Twilio is down, messages pile up and get retried. Your API never blocks.

Here's a clean decision framework for interviews.

Use a queue when:

• Async processing: Anything that doesn't need an immediate response. Sending emails, processing images, generating reports, triggering webhooks.
• Spike absorption: Handle traffic bursts without crashing your downstream services. Black Friday sales, marketing email blasts, viral content notifications.
• Decoupling services: Service A shouldn't need to know whether Service B is up or down right now. The queue absorbs the difference.
• Retry handling: If a downstream service is down, messages stay in the queue until it recovers. No lost work. You can also apply rate limiting on your workers to avoid hammering third-party APIs.

Don't use a queue when:

• Synchronous operations: The user needs an immediate response. Login validation, checkout confirmation, real-time search results.
• Simple CRUD: Operations that complete in milliseconds and return data the user needs right now. Don't over-engineer it.

Rule of thumb: If the user is waiting for the result, don't queue it. If they're not, queue it.

You need to know both, and you need to know when to reach for which one.

RabbitMQ is a push-based broker. It pushes messages to consumers as they arrive.

• Best for: task queues, work distribution, RPC patterns
• Messages are deleted after the consumer acknowledges them
• Lower throughput but rich routing features (exchanges, bindings, dead letter handling)
• Think of it as a job queue where each message gets processed exactly once by one worker

Kafka is a pull-based system. Consumers pull messages at their own pace.

• Best for: event streaming, high-throughput data pipelines, event sourcing
• Messages are retained for a configurable period (e.g., 7 days), even after consumption
• Massive throughput (millions of messages per second)
• Think of it as an append-only log where multiple consumer groups can independently read the same messages

Interview recommendation: For most system design answers, Kafka is the default choice for high-throughput, event-driven systems (notifications, analytics, activity feeds). RabbitMQ is better when you have simpler task-queue patterns (processing uploads, sending individual emails). Know both, default to Kafka when the question involves scale.

A topic is a category of messages (e.g., "notifications", "emails", "user-events"). A partition is a subdivision of that topic for parallelism.

Messages within the same partition are strictly ordered. A consumer group allows multiple workers to process partitions in parallel, where each partition is consumed by exactly one worker in the group. Need more throughput? Add more partitions and more workers. This is horizontal scaling for message processing.

This is critical for notification systems. You cannot let 5 million marketing emails block OTP delivery. Users can't log in? That's a production incident.

The solution: separate queues or topics by priority. Dedicated workers consume from the high-priority queue first.

High Priority Queue:  [OTP] [2FA] [Password Reset]
                       ↓ processed first

Low Priority Queue:   [Marketing] [Newsletter] [Promo]
                       ↓ processed when workers are free

In an interview, mentioning this separation unprompted shows you've thought about real failure scenarios.

Messages that fail processing after N retries go to a dead letter queue. This prevents poison messages (malformed or unprocessable messages) from blocking the entire queue forever.

You can inspect DLQ messages later, fix the bug, and replay them. It's your safety net. A DLQ paired with monitoring and alerting means no message silently disappears.

• At-least-once: A message may be delivered multiple times. Simpler, more common, and usually good enough.
• Exactly-once: Guaranteed single delivery. Much harder. Kafka supports it with idempotent producers and transactional consumers.

For notifications, at-least-once is usually fine. Sending an email twice is annoying but tolerable. Not sending it at all is a bug. The key is to make your consumers idempotent so that processing the same message twice produces the same result. Use a deduplication key (like a message ID) stored in Redis or your cache layer to track what's already been processed. For a deep dive on how to implement this, see Idempotency & Deduplication.

"I'll call Twilio directly from the API handler to send the notification."

Problem: If Twilio is slow or down, your API hangs. The user's request times out. If you're making the call inside a transaction, you might be holding a database lock too. Everything cascades.

Better: Queue the notification, return 202 Accepted, and let workers handle delivery with retries and exponential backoff. Your API stays fast regardless of what Twilio is doing.

"All notifications go into a single queue."

Problem: A marketing blast of 5 million emails blocks OTP delivery for hours. Users can't log in. Customer support gets flooded. Your CEO is asking questions.

Better: Separate queues or topics by priority. High-priority messages (OTP, password resets) get dedicated workers that are never starved by bulk operations.

"Messages just get processed."

Problem: The interviewer wants to know what happens when things fail. And things always fail. Saying nothing about failure handling is a red flag.

Better: Discuss retry with exponential backoff, dead letter queues for poison messages, and idempotent consumers that can safely reprocess duplicates. Show that you've thought about the unhappy path.

"I'll use Kafka as a simple job queue" or "RabbitMQ for event streaming at scale."

Problem: This tells the interviewer you don't understand the fundamental difference between the two. It's like saying you'd use a screwdriver to hammer nails.

Better: Know that Kafka retains messages (it's a log) and RabbitMQ deletes them after consumption (it's a queue). Choose based on the use case. Task distribution? RabbitMQ. High-throughput event pipeline? Kafka.

• Message queues decouple producers from consumers. The producer fires and forgets, the consumer processes at its own pace.
• Use queues for async processing, spike absorption, service decoupling, and retry handling
• Kafka = high-throughput distributed event log (~1M+ msg/sec). RabbitMQ = traditional task queue (~50K msg/sec)
• Priority queues prevent critical messages (OTP, 2FA) from being blocked by bulk operations
• Dead letter queues catch poison messages and prevent queue blockage
• At-least-once delivery + idempotent consumers is the standard production pattern
• Return 202 Accepted from your API when work is queued, not 200 OK

Interview golden rule:

Don't just say "I'll add a queue." Explain what kind
(Kafka vs RabbitMQ), why it's needed (decoupling, retries,
priority), and what happens when messages fail.