Interview Preparation
Every module ends with its own interview questions. This module is the consolidated bank, plus the part that is harder to get from reading: how to structure an answer.
1. What interviewers are actually testing
SQS questions are rarely about SQS. They are a probe for whether you understand distributed systems.
| The question they ask | What they are checking |
|---|---|
| "What is visibility timeout?" | Do you know the API, or do you know why the mechanism exists? |
| "Why can SQS deliver duplicates?" | Do you understand replication and partial failure? |
| "How would you prevent a double charge?" | Can you reason about transaction boundaries? |
| "The queue is growing — what do you do?" | Do you diagnose, or do you guess and scale? |
| "SQS or Kafka?" | Can you make an architectural argument without a slogan? |
A candidate who says "visibility timeout hides the message for 30 seconds" has read the docs. A candidate who says "it is how SQS resolves the ambiguity between a slow consumer and a dead one, which is why no value of it removes the need for idempotency" has understood the system.
2. The question bank
🟢 Beginner — 25 questions
What SQS is · producers and consumers · polling · queue types · the three API calls · what a DLQ is · what long polling is · pricing basics. One-paragraph answers.
🟡 Intermediate — 35 questions
Visibility timeout · why duplicates happen · MessageId vs ReceiptHandle · standard vs FIFO ·
maxReceiveCount · batch semantics · which metrics matter · Lambda event source mappings ·
SNS fanout · identity vs resource policies. Answers with a mechanism, not just a definition.
🔴 Advanced — 40 questions
Idempotency design · FIFO throughput math · head-of-line blocking · backoff implementation · DLQ retention semantics · partial batch failure · consumer scaling limits · capacity math · diagnosing from metric signatures · Spring vs SQS retry semantics · cross-account access. Answers with reasoning, trade-offs and numbers.
⚫ System design — 12 scenarios
Full design questions with a model structure, a reference architecture, the numbers, and the follow-ups an interviewer will push on.
3. Answer frameworks
The mechanism framework (for "what is X?")
What it is (one sentence) → why it exists (the problem) → how it works (the mechanism) → what goes wrong (the production caveat)
Four sentences. Works for visibility timeout, DLQs, long polling, MessageGroupId, receipt handles.
The diagnosis framework (for "X is broken")
Clarify the symptom → name the metrics you would check → enumerate causes → say how you would distinguish them → only then propose a fix
Interviewers are listening for whether you verify before acting. Jumping to "add more consumers" fails this question even when it happens to be the right fix.
The design framework (for "design a system that…")
Clarify requirements (traffic, ordering, latency, failure tolerance) → sketch the flow → choose the queue type and justify it → do the capacity math out loud → design the failure path → monitoring → state the trade-offs you made
The capacity math is the differentiator. Most candidates skip it.
4. The twelve system-design scenarios
| # | Scenario | Tests |
|---|---|---|
| 1 | Order processing at 10,000/sec | Async contracts, capacity math, DLQ design |
| 2 | Prevent duplicate payments | Idempotency, transaction boundaries, external side effects |
| 3 | 1,000,000 events per minute | Throughput math, quotas, cost |
| 4 | Per-customer ordering at scale | FIFO throughput, group key design |
| 5 | Multi-tenant platform with isolation | Bulkheads, fair queues, noisy neighbours |
| 6 | Survive a 6-hour downstream outage | Retention, backoff, circuit breaking, drain time |
| 7 | Add consumers without touching producers | SNS fanout, filter policies |
| 8 | Priority processing | SQS has no priority field — what do you do instead? |
| 9 | Zero-downtime deploys, no duplicates | Graceful shutdown, visibility timeout coordination |
| 10 | File pipeline for 5 GB objects | Claim-check, heartbeating, S3 event semantics |
| 11 | SQS vs Kafka for an event backbone | Replay, consumer groups, TCO |
| 12 | Migrate a legacy monolith | Strangler pattern, anti-corruption layer, dual-running |
Each gets: the clarifying questions to ask, a reference architecture, the numbers, the trade-offs to name, and the follow-up questions to expect.
5. Things that impress, and things that sink you
Impress
- Doing the capacity arithmetic out loud
- Saying "it depends on the p99, not the mean" and meaning it
- Naming a quota before hitting it
- Designing the failure path unprompted
- Saying "I would verify X before changing anything"
- Knowing that the Lambda service polls
Sink
- "FIFO gives exactly-once processing"
- "Just add more consumers"
- "SQS pushes to Lambda"
- "Increase the visibility timeout to stop duplicates"
- Any answer that ignores idempotency
- Quoting the 256 KB message limit (it is 1 MiB — see
aws-facts.md)
6. Revision path
| Time available | Read |
|---|---|
| 5 minutes | revision/sqs-one-page-summary.md |
| 30 minutes | revision/sqs-15-minute-revision.md + this module's §5 |
| 2 hours | revision/sqs-interview-cheatsheet.md + two design scenarios |
| A week | Modules 07, 08, 09, 13, 15, 19, 25, 26 — the ones that get asked |
← Previous: 30 — Capstone Project · Index: Course home