Message Queue Simulator
Visualize how message queues work across Kafka and RabbitMQ patterns. Explore producers, brokers, topics, partitions, exchanges, queues, consumer groups, lag, rebalancing, backpressure, ordering, and dead letter queues.
Category: Infrastructure
What You Will Learn
- How producers, brokers, and consumers interact
- How Kafka partitions and consumer groups affect lag and ordering
- How RabbitMQ exchanges and queue bindings route messages
- How dead letter queues protect systems from poison messages
Topics covered: message-queue, kafka, rabbitmq, queues, streaming, backend, infrastructure, distributed-systems, educational, interactive
// simulator
Message Queue Simulator
Visualize how message queues work across Kafka and RabbitMQ patterns. Explore producers, brokers, topics, partitions, exchanges, queues, consumer groups, lag, rebalancing, backpressure, ordering, and dead letter queues.
// message queue lab
Message Queue Simulator
Visualize producers, brokers, partitions, queues, consumer groups, lag, rebalancing, backpressure, and dead letter handling across Kafka and RabbitMQ style systems.
Append-only partitions retain messages by offset.
Producers
6/tick
Kafka topic
Topic log
key: orders / owner: consumer-1
key: billing / owner: consumer-2
key: email / owner: consumer-1
Consumers
2 active
DLQ
0 dead-lettered
No poison messages yet.
12
3
9
0
Partition 0
offset 1, key orders
Partition 1
offset 2, key billing
Partition 2
offset 3, key email
01 | producer published 12 messages
00 | consumer group started with 2 consumers
// selected scenario
Normal operation
A balanced queue keeps lag low because consumer capacity roughly matches producer throughput.
Ack before work; fast but messages can disappear.
Ack after work; safe but handlers must be idempotent.
Requires broker and consumer coordination, not just a retry loop.
healthy
Throughput 6/tick, capacity 6/tick, backlog 9
Consumers commit offsets after processing for at-least-once delivery.
Consumer groups share partitions. One partition is read by one consumer in a group.
- Topics are append-only logs split into partitions.
- Offsets are the consumer group checkpoint.
- Scaling is limited by partition count per consumer group.
- Ordering is reliable only inside a partition.
- Exchanges route messages into queues through bindings.
- Messages leave a queue when they are acknowledged.
- Prefetch and ack mode control backpressure.
- DLX policies route rejected or expired messages to dead letter queues.
About this message queue simulator
What you'll learn
- How producers send messages through a broker to consumers
- How Kafka partitions and consumer groups create parallelism
- How RabbitMQ exchanges, bindings, queues, and acknowledgments fit together
- Why lag, backpressure, and rebalancing matter during production incidents
- How poison messages move into a dead letter queue for later inspection
Concepts covered
- Kafka: topics, partitions, offsets, consumer groups, ordering, and at-least-once delivery
- RabbitMQ: exchanges, queues, bindings, prefetch, acknowledgments, retries, and DLX policies
- Operations: lag monitoring, rebalancing, poison message handling, and backpressure response
Browser-safe by design
This simulator does not run Kafka or RabbitMQ. It models the queue mechanics in the browser so you can see cause and effect before operating a real broker in production.
The production lesson
Message queues decouple systems, but they do not remove failure. You still need idempotent consumers, lag alerts, retry limits, dead letter handling, and a clear ownership model for messages that cannot be processed.
Overview
A message queue lets producers and consumers work at different speeds, but Kafka and RabbitMQ do it in different ways. This simulator lets you switch between a Kafka topic and a RabbitMQ exchange and run the same scenarios on both. In normal operation producers publish, the broker stores and routes, and consumers keep up. In consumer lag the consumers fall behind and the backlog grows, which is the number to watch in production. Rebalancing restarts a consumer every few ticks: in Kafka the group rebalances and stops consuming while partitions change owner, while RabbitMQ consumers keep going. Ordering guarantees shows that Kafka keeps order only within a partition, so messages for the same key must go to the same partition. Dead letter handling sends poison messages that fail every delivery; each one gets three delivery attempts before it moves to a dead letter queue, so it stops blocking everything behind it. Backpressure shows what happens when the broker or consumers cannot accept more. Seeing both systems handle the same situations makes the trade-off clear: Kafka is a replayable log split into partitions, while RabbitMQ routes messages to queues through exchanges and bindings.
Try this
- Run "Consumer lag" in Kafka mode and watch the backlog grow when consumers fall behind.
- Open "Ordering guarantees" to see why ordering holds only within a single Kafka partition.
- Run "Dead letter handling" and watch a poison message fail its retries, attempt 1, 2 and 3, before it lands in the dead letter queue.
Frequently asked questions
- What is the difference between Kafka and RabbitMQ?
- Kafka is a distributed log: messages are appended to partitions and kept for a retention period, so consumers can replay them. RabbitMQ is a broker that routes messages through exchanges to queues, and messages are usually removed once acknowledged.
- What is consumer lag?
- The difference between the newest message in a partition or queue and the last one a consumer has processed. Growing lag means consumers cannot keep up with producers.
- What is a dead letter queue?
- A queue where messages go after they fail processing too many times or expire. It keeps one bad message from blocking the rest, and lets you inspect and replay failures later.
Try next
// simulator
Caching Strategies Simulator
Learn caching fundamentals with an interactive simulator. Visualize cache hits, misses, eviction policies (LRU, LFU, FIFO), and understand write strategies.
// simulator
Horizontal vs Vertical Scaling Simulator
Interactive game to learn scaling strategies for web applications. Experiment with horizontal and vertical scaling, see the effects on performance, cost, and reliability with realistic pricing simulation and budget constraints.
// simulator
BCDR Simulator
Learn Business Continuity & Disaster Recovery with interactive RTO/RPO planning, failover strategies, and disaster scenarios. Understand hot, warm, and cold DR sites.