The Secret Life of AWS: The Event Bus (Amazon EventBridge)
.jpeg)
How to use Amazon EventBridge to build event-driven architecture.
Part 20 of The Secret Life of AWS
Timothy was feeling good about his queue (Ep 19). The email system was decoupled, and the checkout was fast.
Margaret stopped by his desk, holding a coffee mug. She smiled. "You did a great job decoupling the email service, Timothy. The system is much more resilient."
"Thanks," Timothy said. "I'm ready for whatever's next."
"That’s the spirit," she said gently. "Because the requirements have grown. The business wants to launch a Loyalty Program. When a user buys something, we need to add points to their account."
"Okay," Timothy said, reaching for his keyboard. "I can add a line of code to the Checkout API to call the Loyalty Service."
"There is one more thing," Margaret added. "The Fraud Detection team needs the order data immediately to check for stolen cards. And the Data Science team needs a copy for their analytics."
Timothy frowned, his hands hovering over the keys. "So... I need to modify the Checkout API to call three different services? What if one of them is down? Does the checkout fail?"
He turned to his whiteboard and started drawing lines. Checkout to Loyalty. Checkout to Fraud. Checkout to Data Science. It looked like a spiderweb.
Margaret watched him sketch. "What do you see there, Timothy?"
"I see a mess," Timothy admitted. "My Checkout API knows too much. It has to manage dependencies for teams I don't even work with."
"Exactly," Margaret said softly. "If we keep connecting services directly like this, we create a Distributed Monolith. We lose the agility we just fought for."
She sat down next to him. "Let's try a different approach. Instead of the Checkout API telling everyone what to do, what if it just announced what happened?"
"We need an Event Bus," she suggested. "Let’s look at Amazon EventBridge."
The Hub
Margaret navigated to the Amazon EventBridge console.
"Remember SQS from yesterday?" she asked. "That was like a direct instruction. You told the Email Service specifically to send an email. That is Point-to-Point messaging."
"EventBridge is different," she explained. "It uses the Publish/Subscribe (Pub/Sub) pattern. Your application broadcasts an event—'Order Placed'—into the Bus. It doesn't need to know who is listening."
The Rules
Margaret clicked Create Rule.
"The Bus receives the events," she said. "But we need to tell it where to send them. We use Rules to filter events based on their content."
She showed him the pattern matcher:
{
"source": ["com.timothy.checkout"],
"detail-type": ["OrderPlaced"]
}
"We can create a rule for the Loyalty Service," she explained. "It says: 'If an event comes from Checkout with the type OrderPlaced, send it to the Loyalty Lambda function'."
"Then," she continued, "we create a separate rule for the Fraud Team. Same event, different destination."
The Targets
Timothy’s eyes lit up. "So the Checkout API only sends one message?"
"Exactly," Margaret nodded. "Your code sends one JSON packet to EventBridge. The Bus checks its Rules and routes copies to the Targets."
- Target 1: Loyalty Service (Lambda)
- Target 2: Fraud Detection (SQS)
- Target 3: Data Lake (Firehose)
"If the Fraud team changes their endpoint next week," Margaret noted, "we just update the Rule in EventBridge. You won't have to touch your Checkout code at all."
Extensibility
"What if we add a Shipping Service next month?" Timothy asked.
"What do you think?" Margaret asked back.
"I suppose... we just add a new Rule?"
"Precisely," she smiled. "Your Checkout API doesn't change. You don't even have to redeploy it. You can plug new features into the system without ever risking the core transaction."
The Pattern: Choreography
"There is a name for this architectural style," Margaret explained. "It is called Choreography."
"In other systems, you might have a central controller telling each service exactly what to do—Step 1, then Step 2. That is called Orchestration."
"In Choreography," she continued, "there is no central controller. Each service subscribes to the events it cares about and acts independently. They are autonomous."
"By using events," she summarized, "your services are loose, flexible, and scalable."
Timothy turned back to his screen. He deleted the calls to the Loyalty and Fraud APIs. He replaced them with a single call: PutEvents.
The spiderweb on the whiteboard was gone. Now, there was just a central hub, cleanly routing traffic to the right place.
Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.
Comments
Post a Comment