Messaging Queue
Decouples producers and consumers with buffered, durable message delivery — async work off the critical path.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where Messaging Queue is non-negotiable.
① What it is (30 seconds)
Decouples producers and consumers with buffered, durable message delivery — async work off the critical path.
② How it works in system design
Producer publishes to topic/queue. Consumers pull or subscribe. At-least-once typical; idempotent consumers handle duplicates. Partitioning enables parallel scale.
Typical placement
Client→Edge / Gateway→Messaging→Services→Data stores
③ Concrete system design example
Scenario: Notification system: post-like event → Kafka topic → email, push, SMS consumers at different speeds. User API returns before emails send.
④ Important interview Q&A
| Question | Answer |
|---|---|
| Queue vs pub-sub? | Queue: one consumer per message (task). Pub-sub: many subscribers each get a copy (events). |
| Ordering guarantees? | Single partition preserves order per key; global order needs single partition (limited scale). |
| Poison message? | Retry with backoff → DLQ for manual inspection. |
⑤ Seen in these system designs
- Notifications — multi-channel async
- WhatsApp & Chat — message pipeline
- Apache Kafka — deep dive
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- At-least-once + idempotency
- Partition key
- DLQ
- Consumer lag monitoring
- Backpressure