Message queue simulator

The problem

Work that does not have to happen during a request (emails, image processing, payments to reconcile) is handed to a queue so the request can finish quickly. Consumers then process it at their own pace. Consumers fail, crash and fall behind, and the queue's rules decide whether that work is retried, duplicated or lost.

What you will see

See how the number of consumers and the failure rate drive queue depth, how retries and a dead-letter queue keep poison messages from blocking everyone else, and what acknowledging before or after processing means when a consumer crashes.

Producers, a bounded queue and a pool of consumers, with retries, exponential backoff, a dead-letter queue, backpressure and the difference between at-least-once and at-most-once delivery.

Read next