EventBridge

What is it

• formerly called CloudWatch Events
• a severless "Event Bus" that connects different parts of your application together. Allows services to talk to each other without being directly "plugged into" one another
• a routing engine: receives message, then decides where to send it

Key parts

• The Source (Producer)
• The Event Bus (Router)
• The Rule & Target (Comsumer)

What problems does it solve?

• Old Way (Tight Coupling): If your "Order Service" needs to tell the "Shipping Service," "Email Service," and "Inventory Service" that a sale happened, the Order Service has to have code to talk to all three
• The EventBridge Way (Decoupling): The Order Service just yells "SALE HAPPENED!" into the Event Bus. It doesn't care who is listening. You can add 10 more services to listen to that message without ever touching the original "Order Service" code.
• Pub/Sub Pattern or Event-Driven Architecture

Why is it needed

• Build Event-Driven Apps
• SaaS Integration: the easiest way to get data from non-AWS apps into AWS. You can trigger an AWS Lambda function directly from a Zendesk ticket or a Stripe payment
• Scheduled Tasks: it includes a "Scheduler" that acts like a cloud-based Cron Job (run something at Monday 9:00am)
• Schema Discovery: it can "learn" the structure of your data automatically, so your developers don't have to guess what the "Order" message looks like
  • Schema Gap