We continue in Part VII with Chapter 28: Serverless Architectures at Scale, where we see how to combine the serverless services you already know (Lambda, EventBridge, SQS...) into real and powerful architectures. We start with the most fundamental pattern of the modern serverless world: event-driven architectures, built with Lambda and EventBridge. It's a way of designing systems that scale naturally and remain flexible.

Before combining them, let's recall the pieces (we saw them in Part IV):

• Lambda (Chapter 14): functions that run when something triggers them, without managing servers, and scale on their own.
• EventBridge (subchapter 15.3): the "event bus" that receives events and routes them to the appropriate recipients according to rules.
• SQS, SNS (Chapter 15): queues and notifications to decouple components.

In this subchapter, we put them together to build a complete architectural style.

An event-driven architecture is one where components communicate via events: "something has happened." Instead of one component calling another directly and waiting for its response, it emits an event announcing what happened, and other components react to that event if they're interested.

Analogy: an event-driven architecture works like public announcements at an airport. When it's "announced" that a flight is ready to board (an event), they don't call each person one by one: they make one announcement, and all interested parties (the passengers of that flight) react by heading to the gate. Those not on that flight ignore it. The announcer doesn't need to know who's listening or how many there are. This way, the system is flexible: you can add more "listeners" without changing the emitter.

In the AWS serverless world, this pattern is typically built like this:

• EventBridge is the bus where events travel: it receives events emitted by some components and routes them (with rules, subchapter 15.3) to those that should react.
• Lambda are the functions that react to those events: when an event arrives that matches them, EventBridge triggers them and they do their job.

Each Lambda does one specific thing and runs only when its event arrives, scaling automatically according to how many events come in.

Remember the decoupling we saw with messaging (subchapter 15.4). The one who emits the event doesn't need to know who will process it or how many will do so. This means you can add new reactions without touching the emitting component. Want a notification to be sent when an order is created? You add a new Lambda that listens to that event, without modifying anything existing.

Since each reaction is an independent Lambda that scales on its own (Chapter 14), the system scales naturally with the load. If 10 events or 10,000 arrive, each Lambda multiplies as needed, in parallel. No need to plan capacity.

It's very easy to evolve the system: add, remove, or change reactions to events without rewriting everything. The architecture grows piece by piece, making it ideal for systems that evolve quickly.

If a reacting Lambda fails, it doesn't bring down the rest: the others continue processing their events. And by combining with queues (SQS, subchapter 15.1), events aren't lost even if something temporarily fails.

⚠️ Not everything is an advantage: event-driven architectures are more flexible and scalable, but also more difficult to trace and debug (one event triggers chain reactions throughout the system). This is where distributed tracing (X-Ray, subchapter 24.3) becomes essential, to follow the trail of an event through all the Lambdas it triggers. Also remember the balance between pillars (subchapter 27.1): you gain scalability and flexibility, at the cost of some operational complexity.

Real-world example: an online store processes an order with an event-driven architecture. When a customer buys, the "order created" event is emitted to EventBridge. That single event triggers, in parallel, several independent Lambdas: one charges the payment, another reserves the stock, another sends the confirmation email, another notifies the warehouse, and another logs the sale in analytics. Each does its part without knowing about the others. Months later, the team wants to add a loyalty points program: they simply create a new Lambda that listens to the "order created" event and adds points, without touching anything in the existing flow. The system scales on its own during sales (thousands of orders) and is easy to expand. That flexibility is the essence of event-driven.

• In an event-driven architecture, components communicate via events ("something has happened"): one emits an event and others react, instead of calling each other directly. Like public announcements at an airport.
• It's built with EventBridge as the bus that routes events (by rules) and Lambdas as functions that react, each doing one specific thing and scaling on its own.
• Advantages: decoupling (add reactions without touching existing code), natural scalability (each Lambda scales on its own), flexibility to evolve piece by piece, and resilience (one failure doesn't bring down the rest).
• ⚠️ In return, they're more difficult to trace and debug (chain reactions), so distributed tracing (X-Ray) becomes essential. It's the balance between flexibility and complexity.

In the next subchapter, we'll see how to coordinate multi-step processes that can fail, maintaining consistency, with the Saga pattern.