Managed pending work with explicit completion#
A producer sends work, consumers receive it, and successful workers delete it. SQS owns queue infrastructure; your application still owns idempotency, visibility duration, poison-message policy, and the downstream side effect.
Visibility timeout is a temporary processing lease#
The timeout should cover expected work and can be extended for variable jobs. If it is too short, parallel duplicate processing becomes more likely; too long delays retry after failure. It is not a distributed transaction or an absolute duplicate-prevention lock.
Standard and FIFO make different ordering promises#
| Standard queue | FIFO queue |
|---|---|
| At-least-once delivery | Ordering is scoped by message group |
| Best-effort ordering | Later messages in a group wait behind the in-flight one |
| Consumers must tolerate duplicates | Deduplication has documented scope and conditions; application side effects still need correctness |
A FIFO label does not make an external database update or payment exactly once. Identify the message group, deduplication identity, and side-effect transaction.
Retries and DLQs are operations, not correctness#
Repeated failures can move messages to a dead-letter queue according to policy. A DLQ preserves evidence and protects the hot path, but requires alarms, inspection, repair, and replay. Review retries, DLQs, and idempotent consumers.
Kafka vs RabbitMQ vs SQS#
| Dimension | Kafka | RabbitMQ | SQS |
|---|---|---|---|
| Mental model | Retained partitioned log | Broker, routing, queues | Managed queue |
| Replay/history | Central | Not primary | Not primary |
| Routing | Topics and partition keys | Flexible exchange bindings | Queue-centric; combine AWS services for fan-out |
| Operations | Cluster/platform or managed service | Broker topology or managed service | AWS-managed queue service |
| Ordering | Per partition | Queue/topology and failure dependent | Best effort Standard; message-group scoped FIFO |
| Common fit | Event history and independent groups | Routed brokered work | Straightforward AWS background work |
- Treating receive as acknowledgement; SQS completion requires deletion.
- Assuming visibility eliminates all duplicates.
- Calling Standard ordered or calling FIFO globally ordered without message-group context.
- Using a DLQ without an operational recovery path.
- Choosing Kafka when a managed work queue satisfies the requirement.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- How long is visibility and how is it extended?
- What makes the consumer idempotent?
- Which failures move work to a DLQ?
- Does order matter globally or only per entity?
- Why SQS instead of RabbitMQ or Kafka?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Amazon SQS visibility timeoutAWS Documentation
- Amazon SQS queue typesAWS Documentation