Compare the tools
| Tool | Main job | Example |
|---|---|---|
| SQS | Queue work for consumers | Process uploaded videos |
| SNS | Fan out notifications | Notify multiple subscribers |
| EventBridge | Route matching events | React to application/AWS events |
| Step Functions | Coordinate stateful workflows | Upload → validate → transcode → publish |
A queue stores work until processed or expired. An event bus routes events according to rules. An orchestrator makes workflow state explicit. These can be combined rather than treated as interchangeable names.
SQS lab
- Create a standard queue and a dead-letter queue. Configure a reasonable redrive count and retention.
- Send a JSON message containing an immutable job ID and S3 object key.
- Receive the message. Observe it become invisible temporarily rather than immediately deleted.
- Process it, then delete using the receipt handle returned by that receive.
- Repeat without deletion and wait for visibility expiry; the message becomes eligible for delivery again.
Reliability concepts
Standard queues provide at-least-once delivery and best-effort ordering. Consumers must be idempotent: record a job's unique ID or use a conditional database write so duplicates do not create duplicate side effects. FIFO queues provide additional ordering/deduplication semantics, but external side effects still require careful design. Visibility timeout should cover normal processing with extension where needed. Excessively short values create concurrent duplicates; excessively long values delay recovery. A dead-letter queue needs alarms and a replay/runbook, not silent accumulation.
Workflow lab
Create a small Step Functions workflow with a Pass state followed by a Lambda task. Add bounded Retry and Catch branches for a deliberately simulated transient failure. Use an execution ID to correlate logs. Never retry a charge or destructive operation blindly without an idempotency key.
Verify and cleanup
Show one successful message, one retried message and one intentionally dead-lettered message. Remove event rules, targets, subscriptions, state machines and queues created for the lab. Do not subscribe real third-party email recipients as test destinations.
Official references
Ravindra’s Tip
एक message दो बार आए तो आपका काम दो बार नहीं होना चाहिए। Job ID और idempotency को शुरुआत से design करो।
Interview and revision check
Why delete an SQS message only after successful processing?
Receiving normally hides the message temporarily. Deleting before durable success can lose work; not deleting after success can cause repeats.
Ravindra Bagale · Cloud & DevOps Academy · Handbook and project downloads