6 · Decoupling & Disaster Recovery¶
Domain 2 — Design Resilient Architectures · 26%
Two clusters of questions live here. First, decoupling — pick the right messaging service (SQS vs SNS vs EventBridge vs Kinesis) so components fail and scale independently. Second, disaster recovery — pick the right DR strategy for a given RTO/RPO and budget. Both are pure judgment calls, which is exactly what the exam rewards.
Core concept¶
Decoupling means components talk through a durable intermediary instead of calling each other directly. If the consumer is down or slow, the producer keeps working and messages wait — so a spike or a failure in one part doesn't cascade. The building blocks:
- Queue (SQS) — one producer-side buffer; each message is processed by one consumer, then deleted. Classic work-queue decoupling.
- Pub/sub (SNS) — one message pushed to many subscribers at once (fan-out).
- Event bus (EventBridge) — route events by content-based rules to many targets, from AWS services and SaaS sources; also scheduled events.
- Stream (Kinesis) — ordered, replayable record stream for real-time analytics and multiple independent consumers.
SQS vs SNS vs EventBridge vs Kinesis¶
| Service | Model | Reach for it when… |
|---|---|---|
| SQS | Queue (pull, 1 consumer per message) | Buffer work, smooth spikes, process asynchronously, guarantee nothing is lost while a worker is down |
| SNS | Pub/sub (push, many subscribers) | Fan-out one event to multiple endpoints at once (often SNS → many SQS) |
| EventBridge | Event bus (rules + filtering) | Event-driven routing with rich filtering, AWS-service/SaaS event sources, or scheduled triggers |
| Kinesis | Streaming (ordered, replayable) | Real-time streaming/analytics, ordering, replay, many consumers reading the same data |
Key disambiguations:
- SQS vs Kinesis: SQS deletes a message once processed (work queue); Kinesis retains records so multiple consumers can read and you can replay. "Replay / multiple consumers / ordered stream / real-time analytics" → Kinesis.
- SNS vs EventBridge: both are one-to-many. SNS is simple, high-throughput fan-out (great to SQS/Lambda). EventBridge adds content-based filtering, many AWS/SaaS event sources, a schema registry, and scheduling — reach for it when routing depends on event content or comes from AWS/ partner events.
- Fan-out pattern: SNS → multiple SQS queues durably delivers one event to several independent processors — a very common correct answer.
SQS details worth knowing¶
Standard vs FIFO:
| Standard | FIFO | |
|---|---|---|
| Ordering | Best-effort | Strict order |
| Delivery | At-least-once (rare duplicates) | Exactly-once processing |
| Throughput | Nearly unlimited | ~300 msg/s (up to 3,000 with batching; higher in high-throughput mode) |
Mechanics (verified):
- Visibility timeout — when a consumer receives a message it's hidden for this long (default 30 s, max 12 h) so others don't process it. If the worker doesn't delete it in time, it becomes visible again and may be re-processed → set the timeout longer than your processing time.
- Message retention — default 4 days, min 60 s, max 14 days.
- Max message size — 1 MiB (recently raised from 256 KB); for larger payloads use the SQS Extended Client with S3.
- Dead-letter queue (DLQ) — after
maxReceiveCountfailed processing attempts, a "poison" message is moved to a DLQ for inspection instead of looping forever. - Long polling — set
WaitTimeSeconds(up to 20 s) to cut empty responses and cost.
Disaster recovery — the RTO/RPO ladder¶
Two terms drive every DR question:
- RTO (Recovery Time Objective) — how long you can be down before recovery. Time.
- RPO (Recovery Point Objective) — how much recent data you can afford to lose. Data.
Smaller RTO/RPO = faster recovery and less data loss = more running infrastructure = more cost. The four strategies, cheapest/slowest to priciest/fastest:
| Strategy | What's running in the DR Region | RTO / RPO | Cost |
|---|---|---|---|
| Backup & Restore | Nothing; just backups/snapshots | Hours | 💲 lowest |
| Pilot Light | Only core (e.g. database replicating); app tier off | 10s of minutes | 💲💲 |
| Warm Standby | Scaled-down but running full stack | Minutes | 💲💲💲 |
| Multi-Site Active/Active | Full-scale, serving live in both Regions | Near-zero | 💲💲💲💲 highest |
How to choose on the exam:
- "Cheapest, can tolerate hours of downtime" → Backup & Restore.
- "Core DB always replicated, spin up the rest on failover, tens of minutes" → Pilot Light.
- "A smaller running copy we scale up in minutes" → Warm Standby.
- "Zero/near-zero downtime and data loss, cost is acceptable" → Multi-Site Active/Active.
Worked example — pick the DR strategy¶
A company can tolerate about 10 minutes of downtime (RTO) and roughly 1 minute of data loss (RPO), and wants to keep DR costs as low as possible while still meeting those targets. Its stack is a web/app tier plus a relational database.
Which DR strategy?
Answer
Warm Standby. RTO in minutes rules out Backup & Restore (hours) and Pilot Light (tens of minutes to build the app tier). Multi-Site Active/Active would meet it but is the most expensive and overkill for a 10-minute RTO. Warm Standby keeps a scaled-down but running copy of the full stack in the DR Region with the database continuously replicated (small RPO); on disaster you scale it up and shift traffic within minutes — meeting the targets at lower cost than active-active.
Exam traps¶
- SQS = one consumer per message (work queue); SNS = fan-out to many. Need both → SNS → SQS.
- Kinesis, not SQS, when you need ordering, replay, or multiple consumers of the same stream.
- EventBridge over SNS when routing depends on event content/filtering or comes from AWS/ SaaS sources or a schedule.
- Visibility timeout too short → messages get processed twice; set it > processing time.
- DLQ catches poison messages after
maxReceiveCount— the fix for infinite retry loops. - RTO = time, RPO = data. Smaller = costlier. Map the numbers to the four strategies.
- Backup & Restore = hours; Multi-Site Active/Active = near-zero — the two ends of the ladder.
- FIFO gives ordering + exactly-once but far lower throughput than Standard.
Practice questions¶
Q1. An order service must not lose orders during backend outages or traffic spikes, and each order should be processed exactly once by a single worker. Which service best decouples this?
- A. Amazon SNS
- B. Amazon SQS
- C. Amazon Kinesis Data Streams
- D. AWS Step Functions
Answer: B
B. SQS durably buffers orders so nothing is lost while the backend is down or busy, and each message is processed by one consumer then deleted — the classic work-queue decoupling (use a FIFO queue if strict once-only ordering is required). SNS (A) is fan-out pub/sub. Kinesis (C) is for streaming/replay/multiple consumers. Step Functions (D) orchestrates workflows, not load buffering.
Q2. A single event must be delivered simultaneously to an email notifier, a Lambda function, and an SQS queue for later batch processing. What's the simplest fit?
- A. An SQS queue that all three poll
- B. An SNS topic with the three as subscribers (fan-out)
- C. A Kinesis stream
- D. EventBridge Scheduler
Answer: B
B. SNS pub/sub pushes one message to all subscribers at once (email, Lambda, SQS) — textbook fan-out. A single SQS queue (A) delivers each message to one consumer, not three. Kinesis (C) is streaming, heavier than needed. EventBridge Scheduler (D) is for scheduled triggers, not fan-out.
Q3. A platform must ingest a high-volume real-time clickstream, preserve order, allow multiple independent consumers, and support replaying the last 24 hours of data. Which service?
- A. Amazon SQS standard queue
- B. Amazon SNS
- C. Amazon Kinesis Data Streams
- D. Amazon MQ
Answer: C
C. Kinesis Data Streams preserves order per shard, retains records for replay, and lets multiple consumers read the same data independently — built for real-time streaming/analytics. SQS (A) deletes messages after processing and has no replay/ordering guarantee like this. SNS (B) is fan-out pub/sub. Amazon MQ (D) is a managed broker for existing JMS/AMQP apps.
Q4. A workload can tolerate several hours of downtime and wants the lowest-cost DR approach in a second Region. Which strategy?
- A. Multi-Site Active/Active
- B. Warm Standby
- C. Pilot Light
- D. Backup & Restore
Answer: D
D. With an RTO measured in hours and cost as the priority, Backup & Restore (store backups/snapshots, rebuild on demand) is cheapest. Pilot Light and Warm Standby cost more for faster recovery you don't need; Active/Active is the most expensive.
Q5. Messages in an SQS queue are being processed twice. Workers take about 90 seconds to process a message. What is the most likely cause and fix?
- A. The queue is FIFO; switch to standard.
- B. The visibility timeout (30s default) is shorter than processing time; increase it above 90s.
- C. Long polling is disabled; enable it.
- D. The message retention period is too long.
Answer: B
B. If processing (90s) exceeds the visibility timeout (default 30s), the message becomes visible again and another worker picks it up — causing duplicate processing. Set the visibility timeout comfortably above the processing time (and delete the message on success). The other options don't explain double processing.