Concept explanation
Message queues make backends more resilient, but they introduce new choices around concurrency, retries, and failed jobs. This simulator lets you explore those choices safely.
All games
Message Queue Simulator
Tune workers, retries, and dead-letter behavior while jobs move through an async queue with failures and poison messages.
- Concept
- Async jobs, retries, visibility timeout, and dead-letter queues
- Difficulty
- Intermediate
- Play time
- 7-11 minutes
- Path
- Production Reliability
practice/message-queue-simulator Reliability score Play, get feedback, save local progress, and optionally submit a leaderboard score.
Playable game area
Use the controls below. Feedback appears immediately, and final scores are stored locally.
Leaderboard
Top 10 submitted scores. No account required.
Loading leaderboard...
Finish the game to load your latest local score.
Learning objectives
- Balance worker count, retry count, backlog, and reliability.
- Recognize poison messages and dead-letter queue behavior.
- Explain why idempotency matters when jobs can retry.
How to play
- Choose worker count, retry count, and whether failed jobs should move to a dead-letter queue.
- Start the simulation and watch queue depth change over time.
- Tune settings and rerun to improve successful processing without leaving a large backlog.
Scoring
- Successful jobs add points.
- Backlog, repeated failures, and lost jobs reduce points.
- Dead-letter handling helps preserve reliability when poison messages appear.
Backend concept notes
Queues decouple producers from consumers. They smooth bursts, allow retries, and keep slow work out of synchronous request paths.
Retries improve reliability, but jobs must be idempotent because a retried job may run more than once. Dead-letter queues isolate messages that repeatedly fail.
Common mistakes
- Increasing workers without considering downstream database or API capacity.
- Retrying poison messages forever.
- Making jobs non-idempotent and then duplicating side effects during retries.
FAQ
Short answers for how this game fits backend interview and study practice.
What is a visibility timeout?
It is the period when a claimed message is hidden from other consumers. If processing fails or times out, the message can become visible again for retry.
Why not set retries very high?
High retry counts can hide bugs, waste capacity, and keep poison messages cycling instead of being inspected.