The Problem: Synchronous Coupling
Think of a restaurant where every waiter must personally walk to the kitchen, stand there until the chef finishes cooking, and then carry the plate back. If the kitchen is backed up, every waiter is stuck waiting. If the kitchen catches fire, the entire restaurant stops. This is synchronous coupling — one service directly depends on another being available and fast.
In software, when Service A calls Service B directly via HTTP, the same fragility applies:
- If Service B is slow, Service A hangs and its users wait.
- If Service B is offline, Service A crashes or returns errors.
- If traffic spikes, Service B gets overwhelmed and the failure cascades upstream.
The Solution: Asynchronous Messaging
Instead of Service A calling Service B directly, Service A drops a message into a shared system and immediately moves on. Service B picks up that message whenever it's ready. Neither service needs to know the other is alive at that exact moment.
Amazon SQS (Simple Queue Service) and Amazon SNS (Simple Notification Service) are AWS's foundational tools for this pattern. They are among the oldest AWS services and are battle-tested at massive scale.
- SQS (The Buffer / Queue): Acts like a to-do list. A producer drops tasks onto the list. One or more consumers pick tasks off the list, one at a time, and process them. This is a 1-to-1 (or 1-to-few) pattern — each message is processed by exactly one consumer.
- SNS (The Megaphone / Topic): Acts like a broadcast announcement. A producer publishes one message to a topic. Every subscriber to that topic receives a copy. This is a 1-to-many (fan-out) pattern.
Why This Matters Architecturally
The decoupling benefit goes beyond fault tolerance. It enables independent scaling: if message processing is slow, you scale consumers without touching producers. It enables independent deployment: you can redeploy Service B without coordinating with Service A. And it provides natural backpressure: the queue depth becomes a visible metric you can alarm on, giving you early warning before a system is overwhelmed.
Interviewers often ask: "What's the difference between SQS and SNS?" The trap is giving a one-liner. A strong answer explains the communication pattern: SQS is point-to-point queuing (one consumer processes each message), SNS is publish-subscribe broadcasting (all subscribers get a copy). Then mention that they're most powerful when combined — the fan-out pattern — which shows you understand real-world architecture, not just definitions.