Thinking in Events

In a traditional system, we ask: "What happened?". In Event-Driven Architecture (EDA), we react to things as they happen. It is the architectural equivalent of a "Nervous System."

1. Core Components

• Producers: The service that experienced the state change (e.g., 'OrderService'). It publishes an event like `OrderPlaced`.
• Topics/Exchanges: The mailbox where events are sent.
• Consumers: The services that care about the event (e.g., 'EmailService', 'InventoryService'). They don't talk to the Producer; they only talk to the Topic.

2. Decoupling Logic

The OrderService doesn't know the EmailService exists. This is radical decoupling. If you want to add a 'RewardsService' later, you just point it to the `OrderPlaced` topic. You don't have to change a single line of code in the OrderService. This is how you achieve **Scale and Velocity**.

4. Interview Mastery

Q: "What is the difference between an 'Event' and a 'Command'?"

Architect Answer: "A **Command** is an intent: 'PlaceOrder'. It can be rejected and usually has one receiver. An **Event** is a fact: 'OrderPlaced'. It cannot be undone, it represents something that has already happened, and it can have zero or many receivers. Architecturally, Commands are 'Point-to-Point' while Events are 'Broadcast'."