Concept and mechanism
Messages separate acceptance from processing but introduce states that require tracking. Broker delivery does not establish consumer completion. The contract should explain duplication, ordering, retention, acknowledgment, and failure behavior. SQS standard documentation is an explicit example of at-least-once delivery with possible duplicates. For business effects, consumers need operation identity and protection against reapplying a completed change. A deduplication marker saved after the effect can leave a failure gap. Updating the effect and processing record needs a coherent strategy for the available transaction boundary.
Guided application
In an original exercise, 140 messages arrive per second and 100 complete at constant rates with no loss. The queue grows by 40 per second, or 2400 per minute. More consumers help only within database and dependency capacity. Observe oldest-message age as well as depth: a small backlog can contain stalled urgent work. Repeatedly failing messages should be isolated with diagnosis and ownership, retaining data only in authorized locations. Before redrive, fix the cause, assess idempotency, and control the rate. When order matters, moving an item to a DLQ can let later items proceed outside the intended business sequence.
140 arrivals/s minus 100 completions/s accumulate 2400 messages in a minute.
Common pitfalls
Queue as infinite capacity; acknowledgment as business success; redrive without fixing the cause.
Related topics: Boundaries and contracts · Data and distributed transactions · Resilience and load
Connect each message to the operation state it represents.
Reference: Queue-based load leveling · Microservice architecture patterns and scoped platform examples; primary guidance consulted 2026-09-30