Decoupling: SQS, SNS & EventBridge

Queues, pub/sub, and event-driven design.

Loosely-coupled architectures are more resilient and scalable than tightly-coupled ones, because components can fail, scale, and evolve independently. AWS provides managed messaging and eventing services to decouple systems.

Queues and pub/sub

Amazon SQS is a managed message queue that decouples a producer from a consumer: the producer drops work on the queue and the consumer processes it at its own pace, so a traffic spike fills the queue rather than overwhelming downstream — the queue absorbs the burst and consumers (often an Auto Scaling group) drain it. Amazon SNS is pub/sub: one published message fans out to many subscribers (queues, Lambda functions, HTTP endpoints), so multiple systems react to the same event without the publisher knowing about them. A common pattern combines them — SNS fans an event out to several SQS queues, each feeding a different consumer — giving reliable, decoupled, parallel processing.

# Absorb spikes: producer never blocks; consumers scale to drain the queue.
producer ──▶ SQS queue ──▶ Auto Scaling consumer fleet
                           (spike fills the queue, not the consumers)
 
# Fan out one event to many independent reactions:
event ──▶ SNS topic ──┬─▶ SQS (order processing)
                      ├─▶ Lambda (send email)
                      └─▶ SQS (analytics)
# EventBridge routes events between services by rules (event-driven integration).

Event-driven integration

Amazon EventBridge extends this to a full event bus: services emit events and rules route them to targets, enabling loosely-coupled, event-driven architectures where adding a new consumer is a rule change, not a code change to the producer. The architectural payoff of decoupling is significant: a slow or failed consumer does not break the producer, each component scales independently to its own load, and you can evolve or replace pieces without ripple effects. Combined with stateless, auto-scaling tiers, decoupled messaging is what lets an AWS architecture stay responsive and resilient under uneven, bursty, real-world traffic rather than failing when one component is overwhelmed.