Competing consumers
Several workers share one queue. How far does adding them take you, what happens when one crashes, and what do you scale them on?
13 minMediumStation: Competing consumersMembers lesson
Membership isn’t open yet. The free lessons are open — 16 of them.
- Pixel's postsUsers
- Notify APIWeb API
- Send queueQueue
- SenderWorker
- Push provider's cap (300/s)Rate limiter
- Push providerService
What you'll be able to do
- 1Predict a queue's throughput and backlog as workers are added, up to the point where a shared downstream — a provider's cap, a database — becomes the bottleneck.
- 2Explain why a crashed worker's message isn't lost — it stays hidden in the queue until the worker reports it done — and why that means a message can be processed twice.
- 3Choose how many workers to run and what to scale them on — the backlog per worker against the wait you can accept — and spot work that can't be shared out because it must stay in order.
Inside the lesson
- steps
- 12
- questions
- 7
- simulations
- 4
You guess first, then run the system and see if you were right.
Step 1 · The setup
Notify's send queue from the last stop works. Posts have grown to about 80 a second, so Notify moves to a bigger plan: the provider now takes up to 300 sends a second.
Last stop the sender's pace was a setting chosen against the cap. On the bigger plan the limit is the sender's own server: it manages about 100 sends a second (in this sim, a setting), so one sender can't use the new cap. Then comes a launch: a wave of 400 posts a second for 10 seconds.
Watch it with one sender.
Steps 2–12 are for members