Backend Study Lab · Games
← 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

Interactive scenario

Playable game area: Make the next backend decision

Use the controls below. Feedback appears immediately and final scores stay in this browser.

Concept notes

Why this decision matters

Message Queue Simulator is focused practice for Async jobs, retries, visibility timeout, and dead-letter queues. It explains why each answer is safe, risky, or production-ready.

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.

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

  1. Read the queue scenario and its evidence about retries, workers, or failed deliveries.
  2. Choose one strategy that best addresses the queue risk described.
  3. Select Submit decision, read the explanation, then choose Next challenge or Finish run.
  4. The gauges illustrate the scenario; they do not measure live jobs, backlog, or delivery success.

Scoring

  • Your score ranges from 0 to 1000 and reflects the quality of your decisions.
  • Consistently strong decisions at harder difficulty levels earn an extra bonus.
  • Completing all eight decisions adds a completion bonus.
  • Response time does not affect your score. Take time to read the evidence and explanations.

Backend concept notes

Queues decouple producers from consumers. They smooth bursts, allow retries, and keep slow work out of synchronous request paths.

This simulator models queue capacity and at-least-once delivery attempts. Broker delivery is not the same as exactly-once business processing: consumer deduplication and transactional side-effect boundaries are practiced separately in Idempotent Consumer Lab.

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.

Review misses from this game

Related Backend Study Lab tools

Use tools from the main site when you want to inspect real inputs.

Keep practicing nearby backend concepts while the mental model is fresh.

APIs Beginner

API Route Builder

Design REST-style methods and routes for product requirements such as creating users, updating email, searching products, and nested comments.

Time
6-9 minutes
Concept
REST API route design
  • Foundations
  • REST
  • API design
  • routes
Play API Route Builder
Scaling Intermediate

Load Balancer Challenge

Route simulated traffic across backend servers using round robin, weighted round robin, least connections, and random strategies.

Time
6-10 minutes
Concept
Load balancing strategies
  • Production Reliability
  • load balancing
  • scaling
  • latency
Play Load Balancer Challenge

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.

Leaderboard

Top 10 scores for the current ruleset. No account required.

Loading leaderboard...

    Finish the game to load your latest local score.