Event-Driven Architecture is a software architecture pattern promoting the production, detection, consumption of, and reaction to events.

Think of a Fire Alarm in a School:

1. The Event: Someone pulls the handle (An event occurs).
2. The Reaction:
   • The bells ring (Notification Service).
   • The sprinklers turn on (Safety Service).
   • The fire department is called (Emergency Service).
3. Decoupling: The person who pulled the handle didn't have to walk to the bells, the sprinklers, and the phone. They just created the Event, and everyone else reacted to it!

---

Components of EDA

1. Event Producers: The component that emits the event (e.g., "User clicked Buy").
2. Event Channels: The pipes that carry the event (e.g., Message Queues like Kafka).
3. Event Consumers: The services that wait for events and perform an action.

Benefits

• Asynchronous: Producers don't wait for consumers to finish.
• Scalability: You can add 100 consumers to the same event channel.
• Flexibility: You can add a new service (e.g., "Analytics") just by having it listen to the existing events. You don't need to change the code of the producer.

---

Synchronous (REST) vs Asynchronous (EDA)

• REST: "Hey Order Service, create an order and let me know when you're done." (Blocking).
• EDA: "Hey world, an order was placed. Do what you need to do." (Non-blocking).

The Challenge: "Eventual Consistency"

Because everything is async, you might have a situation where the "Order" is created but the "Email Notification" hasn't been sent yet. This is normal in EDA, and you must design your UI to handle it (e.g., "We've received your order and is being processed").

Patterns to know

• CQRS (Command Query Responsibility Segregation).
• Event Sourcing: Storing every single change as an event, rather than just storing the current state in a database. 🌋