← AWS Solutions Architect Associate: architecture decisions
07 / 8 · 25 MIN

Events, queues, and processing

Design consumers that tolerate repetition, failures, and load variation.

Concept and mechanism

SQS Standard permits repeated delivery; the application should protect business effects against duplication. Visibility timeout keeps a message temporarily unavailable to other consumers after receipt, but it is not an exactly-once execution guarantee. Size or extend the period according to the work and delete the message only after confirming the required result. A DLQ isolates persistent failures according to configured policy; the message still represents unresolved work. Redrive requires understanding the cause to avoid recreating the same incident.

Guided application

If audit and reconciliation need every event, use a fanout design, for example SNS with one SQS queue per consumer. Two consumers of the same queue share work; they do not necessarily each receive every event. To scale workers, backlog per instance relates pending work to capacity. An initial calculation divides accepted delay by average message processing time; then validate distribution, concurrency, and peaks. Lambda functions may suit short event-driven tasks, but dependencies, limits, connectivity, and total cost still guide selection.

IN PRACTICE

At two seconds per message and forty seconds of accepted delay, the initial target is twenty messages per worker. Real variability may require headroom and another policy.

Common pitfalls

Deleting before confirming the effect; confusing DLQ with success; adding workers without observing the destination system’s limit.

Related topics: Costs, commitments, and retirement · Identity, trust, and permissions

Take this idea with you

Decoupling requires handling state, repetition, and failures beyond creating the queue.

Create account

Reference: SQS standard queues · SAA-C03