Skip to content

6 · Decoupling & Disaster Recovery — Revise

Resilient · 26% · Compressed recall. Read the Learn guide first.

Messaging service picker

Service Model Reach for it when
SQS Queue, 1 consumer/msg Buffer work, smooth spikes, nothing lost while worker down
SNS Pub/sub, many subscribers Fan-out one event to many (often SNS → SQS)
EventBridge Event bus + rules Content filtering, AWS/SaaS sources, scheduling
Kinesis Streaming, ordered, replay Real-time analytics, ordering, replay, many consumers 
Work queue, process once, nothing lost?     → SQS
Deliver one event to many endpoints?        → SNS (fan-out; SNS→SQS for durable)
Route by event content / AWS-SaaS events?   → EventBridge
Ordered, replayable stream, many readers?   → Kinesis

SQS facts

Fact Value
Standard At-least-once, best-effort order, ~unlimited throughput
FIFO Exactly-once, strict order, ~300/s (3,000 batched)
Visibility timeout Default 30 s, max 12 h (set > processing time)
Message retention Default 4 days, max 14 days
Max message size 1 MiB (larger → S3 + Extended Client)
DLQ Poison messages after maxReceiveCount
Long polling WaitTimeSeconds up to 20 s

DR strategies (RTO/RPO ladder)

Strategy Running in DR Region RTO/RPO Cost
Backup & Restore Nothing (backups only) Hours 💲
Pilot Light Core (DB replicating), app off 10s of min 💲💲
Warm Standby Scaled-down full stack running Minutes 💲💲💲
Multi-Site Active/Active Full-scale live in both Near-zero 💲💲💲💲

RTO = time to recover. RPO = data you can lose. Smaller = costlier.

Flashcards

SQS vs Kinesis? SQS deletes a message after one consumer processes it (work queue). Kinesis retains records for ordering, replay, and multiple consumers.
SNS vs EventBridge? Both one-to-many. SNS = simple high-throughput fan-out (→ SQS/Lambda). EventBridge = content-based rules, AWS/SaaS event sources, schema registry, scheduling.
Deliver one event durably to several independent processors? SNS → multiple SQS queues (fan-out).
Messages processed twice; workers take 90s. Fix? Visibility timeout (default 30s) is shorter than processing time — raise it above 90s.
What catches poison messages that keep failing? A dead-letter queue (DLQ), after maxReceiveCount attempts.
RTO vs RPO? RTO = how long to recover (time). RPO = how much data loss is acceptable (data / point in time).
Cheapest DR, hours of downtime OK? Backup & Restore.
Near-zero RTO/RPO, cost acceptable? Multi-Site Active/Active.
Core DB always replicated, spin up the rest on failover (tens of minutes)? Pilot Light.
Scaled-down running copy, scale up in minutes? Warm Standby.

Common traps

  • SQS one consumer/msg; SNS fan-out — combine as SNS → SQS.
  • Kinesis for ordering/replay/multiple consumers, not SQS.
  • EventBridge when routing on content or AWS/SaaS events or schedules.
  • Visibility timeout > processing time or you double-process.
  • RTO = time, RPO = data; smaller = costlier.
  • Backup & Restore (hours) ↔ Active/Active (near-zero) are the ends of the ladder.