We close the messaging chapter by putting the pieces together (SQS, SNS, EventBridge) into the major architecture patterns they enable. More than specific services, here we talk about ways to design systems that are robust, flexible, and scalable. Understanding these patterns makes you an architect, not just a service user.

We already saw this with SNS (subchapter 15.2): a publisher emits a message and many subscribers receive it, without the publisher knowing who they are.

The underlying idea: whoever emits the event does not know nor care who will receive it. This allows you to add new subscribers without touching the publisher.

Example: today, when there’s a new order, you notify billing and inventory. Tomorrow, marketing also wants to know to send offers. With pub/sub, you just add a subscriber to the topic; the order service remains untouched. The system grows without breaking what already exists.

It’s implemented with SNS (simple broadcast) or EventBridge (smart routing).

This is perhaps the most important pattern in the whole chapter. Decoupling means that the components of a system do not depend directly on each other: they communicate through an intermediary (a queue or a bus), not by “calling” each other.

The advantages of decoupling (which we already saw with SQS, subchapter 15.1):

• Resilience: if one component fails, the others keep working; messages wait.
• Independent scaling: you can scale each component separately according to its load.
• Maintainability: you can change, update, or replace a component without affecting the others (as long as it respects the message format).
• Peak smoothing: the queue absorbs traffic spikes.

Analogy: a coupled system is like a phone conversation: both have to be available at the same time; if one doesn’t answer, there’s no communication. A decoupled system is like sending a WhatsApp message: you send it and move on; the other person reads it when they can. Much more flexible and resilient.

Decoupling is achieved with queues (SQS), notifications (SNS), and event buses (EventBridge): all the pieces from this chapter.

This one is more advanced, but it’s good to know. It arises from a real problem: how do you coordinate an operation that affects several services, when one might fail halfway through?

Imagine a purchase that involves three steps in three different services:

What happens if step 1 (charge) succeeds, but step 2 (inventory) fails because there’s no stock? You’ve charged the customer for a product you can’t deliver. In a single system you’d use a “transaction” that undoes everything at once, but here they are separate services: there’s no single transaction that covers them all.

A saga breaks the operation into a sequence of steps, where each step has a defined compensating action (how to undo it). If a step fails, the compensations for the previous steps are executed in reverse order, leaving the system consistent.

Analogy: a saga is like a travel reservation with flight, hotel, and car. If you book the flight and hotel, but there are no cars available, you don’t end up with a useless flight and hotel: the system cancels (compensates) the flight and hotel to leave you as you were. Each reservation knows how to cancel itself.

In AWS, sagas are often orchestrated with Step Functions (we’ll see this in Chapter 28), which coordinates the steps and compensations, relying on queues and events to communicate between services.

All these patterns share the same philosophy, that of event-driven architectures: instead of a big monolithic system where everything is intertwined, you build small, independent components that communicate via messages and events. The result: more resilient systems (a failure doesn’t bring down everything), more scalable (each piece scales on its own), and easier to evolve (you add pieces without breaking the others).

• Pub/Sub: the sender publishes and many receive, without knowing them; allows you to add subscribers without touching the publisher. Done with SNS or EventBridge.
• Decoupling (the most important pattern): services communicate via queues/buses, not directly. Brings resilience, independent scaling, maintainability, and peak smoothing. Like moving from a phone call to WhatsApp.
• Saga: coordinates an operation across multiple services by defining, for each step, a compensating action that undoes it if something fails, keeping the system consistent. Orchestrated with Step Functions (Chapter 28).
• All share the event-driven philosophy: small, independent components communicating via events, more resilient, scalable, and evolvable.

You’ve finished Chapter 15! You now know how to connect and decouple services. In Chapter 16 we change topics to content delivery and DNS: how users reach your application quickly and securely (Route 53, CloudFront, SSL certificates, and WAF).