Distributed Systems Playground
A message queue you can break on purpose. Change the number of consumers, the failure rate and the visibility timeout, and watch what happens to each message.
Simulation ModeRuns entirely in your browser. No requests to AWS: every number on this page is computed by the simulator.
Scenarios
What to watch: A message only leaves the queue when the consumer deletes it (DeleteMessage). Receiving is not consuming.
Ready to start.
Legend
- First attempt
- Received again (number = receives)
- Poison message
- Copy delivered twice
- Still processing with an expired receipt handle
Configuration
Records every processed message and skips repeats.
The same seed always produces the same run.
Simulator metrics
- Simulated time
- 0.0 s
- Sent
- 0
- Available
- 0
- Processing
- 0
- Waiting retry
- 0
- Completed
- 0
- Attempts
- 0
- Failures
- 0
- In the DLQ
- 0
- Throughput
- 0.0 msg/s
- Average time
- 0.0 s
- Duplicate effects
- 0
- Duplicates skipped
- 0
Events
No events yet.
State of each message
| Message | State | Receives | Effects applied |
|---|---|---|---|
| M01 | At the producer | 0 | 0 |
| M02 | At the producer | 0 | 0 |
| M03 | At the producer | 0 | 0 |
| M04 | At the producer | 0 | 0 |
| M05 | At the producer | 0 | 0 |
| M06 | At the producer | 0 | 0 |
| M07 | At the producer | 0 | 0 |
| M08 | At the producer | 0 | 0 |
What this simulation shows
At-least-once
SQS Standard guarantees each message is delivered at least once, not exactly once. Duplicates are rare, but the consumer has to tolerate them.
No guaranteed order
Order is best effort in a Standard queue. With several consumers and retries, completion order drifts even further from send order. When order matters, a FIFO queue is the option, with other limits.
Visibility timeout
Receiving hides a message for a while. If the consumer does not delete it within that time, because it failed, hung or was slow, it becomes visible and is delivered again.
Dead-letter queue
Each receive adds 1 to the receive count. Once it goes past the redrive policy's maxReceiveCount, SQS moves the message to the DLQ instead of delivering it again.
Idempotency
An idempotent consumer produces the same result when the same message arrives twice. Here it records the id of each processed message and skips repeats.
Concurrency
More consumers raise throughput while there are messages available. They also raise contention on shared resources and the chance of handling duplicates at the same time.
Deliberate simplifications
- It does not reproduce AWS's internal scheduling: timing, order and duplicates follow simple rules and a seed.
- Each consumer receives one message at a time. The real Lambda receives batches of up to 10.
- A message goes to the DLQ as soon as it reappears at the limit. SQS does it on the next receive attempt.
- Duplicate copies are not delivered again if they fail.
- The visibility timeout is fixed: no consumer extends it, and there is no backoff between attempts.
AWS Live Mode
There is a real version of this experiment: API Gateway, a Lambda that produces messages, an SQS Standard queue with a DLQ and a consumer Lambda with partial batch responses. It runs in my AWS account, so it is restricted to the admin area, with limits on messages and runs per day.
API Gateway (authenticated route) → producer Lambda → SendMessageBatchSQS Standard queue → event source mapping → consumer LambdaFailure: the message comes back after a delay; after 3 receives it goes to the DLQEach message's state in DynamoDB, followed by polling
This page never calls AWS. The real mode requires an admin sign-in.