22. Message Queues
1
The picture to keep in your head2
22.1 What are producers and consumers?3
22.2 Why go async?4
22.3 What are the delivery guarantees?5
22.4 How do acks and visibility timeouts work?6
22.5 What are retries and dead-letter queues?7
22.6 What is an idempotent consumer?8
22.7 How does ordering work?9
22.8 What is backpressure?10
22.9 How do you scale consumers?11
22.10 Log (Kafka) vs queue (RabbitMQ, SQS): what's the difference?12
22.11 How do delayed and scheduled jobs work?13
Memory card and where the analogy breaks14
Practice: five levels15
Interview questions16
Solutions17
Sources18
Code lab22. Message Queues
22.9 How do you scale consumers?
3 min read+10 XP
At the bank: More customers per hour than one clerk can serve? Open more counters. How many? Customers per hour × minutes per customer ÷ 60.
In the system: Consumers are usually stateless, so you scale them by adding more. How many you need follows from Little's law: workers busy at once = arrival rate × time per message.
- 1,000 messages a second × 0.2 seconds each = 200 messages in progress at once, so 200 concurrent workers (threads, processes or async tasks).
- Add headroom for spikes and slow periods: with 50%, 300.
Practical points:
- Autoscale on queue depth or the age of the oldest message, not just CPU: a worker waiting on a slow SMS gateway shows low CPU but a growing queue.
- Watch the downstream. More workers mean more calls to the SMS gateway or database. If it allows 500 calls a second, 1,000 workers won't help; they'll just fail faster. Limit concurrency to what the downstream can take.
- Kafka's limit: within a consumer group, each partition is read by one consumer, so a topic with 12 partitions can use at most 12 consumers in a group. Choose partition counts with growth in mind.
- Batch where possible: receiving and acking 10 messages per call cuts overhead.
Memory code: "Counters needed = customers per minute × minutes each."