Hands-on Labs
Reading about visibility timeout and watching a message reappear 30 seconds after you killed a consumer are different experiences. These labs are the second one.
Every lab is self-contained, runs in a single AWS account, and ends with a teardown step.
Before you start
- Complete Module 00 — credentials, CLI, Java 21, SDK v2
- Set a billing alarm. Every lab below fits inside the free tier if you tear down, and none of them fit if you leave a tight-poll loop running for a week
- Use a dedicated prefix (
sqs-course-*) for every resource so teardown is easy - Work in one Region and stay in it
Lab format
Each lab file follows the same shape:
- Goal — the one thing this lab makes real
- Module — what to read first
- Estimated time and estimated cost
- Setup — resources to create (CLI and IaC)
- Steps — numbered, copy-pasteable
- What you should observe — the specific output or metric that proves the point
- Why it happened — tying the observation back to the mechanism
- Experiments — deliberate variations to try
- Teardown — every resource, in order
The labs
| # | Lab | What it makes real | Read first |
|---|---|---|---|
| 01 | Create your first queue | Queue URL vs ARN, the attributes that matter on day one | 04 |
| 02 | Send and receive a message | The three-call round trip; MessageId vs ReceiptHandle | 04 |
| 03 | Watch visibility timeout | A message going invisible, then coming back | 08 |
| 04 | Force a redelivery | Kill a consumer mid-processing; watch ApproximateReceiveCount climb | 05, 08 |
| 05 | Configure a DLQ | A poison message landing in quarantine after exactly maxReceiveCount receives | 11 |
| 06 | FIFO ordering and message groups | Ordering inside a group; parallelism across groups; head-of-line blocking | 07 |
| 07 | Long polling vs short polling | Count the API calls both ways; see empty receives vanish | 12 |
| 08 | Batch APIs | Same throughput, one tenth the API calls; handle a partial failure | 13 |
| 09 | Build a Java consumer | A correct poll loop with SDK v2 | 04, 12 |
| 10 | Spring Boot producer and consumer | SqsTemplate and @SqsListener end to end | 23 |
| 11 | SQS + Lambda | The whole-batch-retry bug, then ReportBatchItemFailures fixing it | 19 |
| 12 | SNS → SQS fanout | One publish, two queues, a filter policy | 20 |
| 13 | S3 → SQS | Upload triggers a message; the multipart-upload trap | 21 |
| 14 | Implement idempotency | Deliberately deliver twice; prove the effect happened once | 09 |
| 15 | Production-style worker service | Bounded pool, heartbeat, graceful shutdown, metrics | 14, 22 |
| 16 | Monitor with CloudWatch | A dashboard and alarms that actually fire on the right thing | 17 |
| 17 | Break it and fix it | An injected failure, diagnosed from metrics alone | 26 |
Suggested tracks
Weekend fundamentals (labs 1–5) — enough to be useful on a real queue.
Interview prep (labs 1–8, 11, 14) — every mechanism that gets asked about.
Production readiness (labs 9, 10, 14, 15, 16, 17) — what you need before you own a queue on call.
Teardown
Each lab ends with its own teardown. A sweep script that removes every sqs-course-* resource in
the Region lives in this directory — run it when you finish.
⚠️ The sweep script deletes queues and their messages permanently. Read it before running it.
← Previous: 28 — Corporate Case Studies · Index: Course home · Next: 30 — Capstone Project →