The Secret Life of AWS: Event-Driven Architecture (Amazon EventBridge)

 

The Secret Life of AWS: Event-Driven Architecture (Amazon EventBridge)

(Part 60 of The Secret Life of AWS)

How to decouple your microservices and scale seamlessly using an event bus

#AWS #EventBridge #CloudArchitecture #Serverless




Margaret is a senior software engineer. Timothy is her junior colleague. They work in a grand Victorian library in London — the kind of place where code quality is the unspoken objective, and craftsmanship is the only thing that matters.

Episode 60

Timothy was reviewing the X-Ray trace map for his newly released checkout feature. The business logic was working flawlessly thanks to the AppConfig feature flag, but the performance metrics were alarming.

"The checkout microservice is taking almost four seconds to execute," Timothy explained to Margaret, pointing at the latency graph. "When a customer clicks 'Buy', the Lambda function charges the credit card. Then, it makes a synchronous API call to the Inventory Service to reserve the item. Then, it calls the Shipping Service to generate a label. Finally, it calls the Email Service to send the receipt. If any of those downstream services are slow, the customer is left staring at a spinning loading wheel."

"And what happens if the Email Service goes down completely?" Margaret asked.

Timothy grimaced. "The checkout Lambda throws an error, and the entire order fails. The customer cannot buy the product just because our receipt generator is offline."

"After sixty episodes of building, you have reached the limits of a tightly coupled system," Margaret said. "Your checkout service knows too much. It should not care about shipping labels or email receipts. It should only care about taking the payment. We need to implement an Event-Driven Architecture using Amazon EventBridge."

The Central Event Bus

Margaret opened the AWS Console and navigated to EventBridge.

"EventBridge is a serverless event bus," she explained. "Instead of your checkout service making synchronous, point-to-point API calls to every other service, we are going to place EventBridge in the middle. The checkout service will simply announce what happened, and EventBridge will route that announcement to anyone who cares. With EventBridge's Schema Registry, it can even auto-discover and version your events so all downstream consumers know exactly what data structure to expect."

Margaret opened Timothy's Node.js code and deleted the API calls to Inventory, Shipping, and Email. She replaced them with a single SDK call:

const { EventBridgeClient, PutEventsCommand } = require("@aws-sdk/client-eventbridge");
const client = new EventBridgeClient({ region: "us-east-1" });

async function processCheckout(order) {
    // 1. Charge the credit card
    await chargeCard(order);

    // 2. Announce the event to the bus
    const command = new PutEventsCommand({
        Entries: [{
            Source: "com.mystore.checkout",
            DetailType: "OrderPlaced",
            Detail: JSON.stringify(order),
            EventBusName: "default"
        }]
    });
    
    await client.send(command);
    return { status: "Success" };
}

"One detail to remember," Margaret noted. "EventBridge has a 256KB payload limit. If your order JSON ever exceeds that, we will use the Claim-Check pattern—storing the large blob in S3 and just passing the S3 reference through the event bus."

Choreography and Rules

"Notice the paradigm shift," Margaret pointed out. "The checkout service no longer commands the email service to send a receipt. It simply emits a fact: an OrderPlaced event has occurred. Its job is done. The Lambda function finishes executing in 200 milliseconds, and the customer instantly sees a success screen."

"But how do the other services know to do their jobs?" Timothy asked.

"We create Rules on the Event Bus," Margaret explained. She created a new rule in the console, telling EventBridge to listen for any event where the Source is com.mystore.checkout and the DetailType is OrderPlaced.

"We attach the Inventory, Shipping, and Email services as Targets to this rule," she said. "When EventBridge receives the OrderPlaced event, it simultaneously fans out a copy of that event to all three targets. They process the data asynchronously, in parallel."

The Ultimate Extensibility

Timothy immediately recognized the architectural power. "If the Email Service is offline, the checkout still succeeds. And just like we did with SQS in Episode 46, EventBridge can send that failed email event to a Dead Letter Queue to be processed later when the service recovers."

"Exactly," Margaret smiled. "And consider the extensibility. Next month, the Marketing team wants to start sending a welcome text message for every new order. In your old architecture, you would have to modify the checkout code, add another API call, write more unit tests, and risk breaking the payment logic."

"And with EventBridge?"

"You touch absolutely nothing," Margaret said. "You just build the new SMS Lambda function and attach it as a fourth target to the existing EventBridge Rule. The checkout service never even knows the SMS service exists."

Timothy updated his architecture diagram. He had fundamentally transformed his application from a rigid, monolithic workflow into a highly decoupled, infinitely scalable ecosystem.


Key Concepts Introduced:

Tight Coupling vs. Decoupling: In a tightly coupled architecture, microservices communicate directly via synchronous point-to-point API calls. If a downstream service is slow or fails, the upstream service is directly impacted, creating cascading failures and high latency. Decoupling separates these services so they operate independently, increasing system resilience and performance.

Event-Driven Architecture (EDA): A software design pattern where decoupled applications asynchronously publish and subscribe to "events" (state changes or facts, such as an item being purchased). The publisher of the event has no knowledge of who is listening or how the event will be processed.

Amazon EventBridge: A serverless event bus that routes data from your applications to targeted AWS services. It utilizes Rules to filter incoming events (e.g., matching a specific DetailType) and securely routes the payload to multiple Targets simultaneously (fan-out pattern).

EDA Best Practices: EventBridge features a Schema Registry to auto-discover and version event structures for downstream consumers. Because events have a 256KB size limit, architects use the Claim-Check pattern (storing large payloads in Amazon S3 and passing the URI in the event) for massive payloads. Finally, EventBridge natively supports Dead Letter Queues (DLQs) to capture and retain events if a target service is offline, ensuring zero data loss.


Aaron Rose is a software engineer and technology writer at tech-reader.blog

Catch up on the latest explainer videos, podcasts, and industry discussions below.


Comments

Popular posts from this blog

Insight: The Great Minimal OS Showdown—DietPi vs Raspberry Pi OS Lite

The New ChatGPT Reason Feature: What It Is and Why You Should Use It

Raspberry Pi Connect vs. RealVNC: A Comprehensive Comparison