Event-Driven Architecture

In a traditional request-driven architecture, Service A directly calls Service B, waits for a response, and then proceeds. In an Event-Driven Architecture (EDA), services communicate by producing and consuming Events—immutable records of something that happened (e.g., "Order Placed", "Payment Completed", "User Registered").

1. Core Components

• Event: A lightweight notification that something significant happened. It contains metadata (timestamp, source) and relevant data. Example: { "event": "OrderPlaced", "orderId": 12345, "userId": 67890, "total": 99.99 }.
• Event Producer: The service that detects a change and publishes an event. The Order Service is a producer of "OrderPlaced" events.
• Event Broker: The central message infrastructure (Kafka, RabbitMQ, AWS EventBridge) that receives events from producers and delivers them to consumers.
• Event Consumer: A service that subscribes to specific event types and reacts to them. The Email Service consumes "OrderPlaced" events to send confirmation emails.

2. Patterns

Event Notification

The simplest pattern. A producer publishes a lightweight event, and consumers react independently. The producer doesn't know or care who consumes the event.

• Example: User Service publishes "UserRegistered". The Email Service sends a welcome email, the Analytics Service logs the signup, and the Recommendation Service initializes the user's preferences. All three happen independently and concurrently.

Event-Carried State Transfer

The event itself contains all the data the consumer needs, so the consumer doesn't need to make a callback to the producer's API.

• Instead of { "event": "UserUpdated", "userId": 123 }, the event carries the full state: { "event": "UserUpdated", "userId": 123, "name": "Alice", "email": "alice@example.com" }.

Event Sourcing

Instead of storing the current state of an entity, the system stores a complete, ordered log of every event that ever happened to that entity. The current state is derived by replaying all events.

• Example: A bank account doesn't store balance: $500. It stores: AccountOpened($0), Deposited($1000), Withdrew($300), Deposited($200), Withdrew($400). The balance is calculated by replaying these events.
• Advantage: Complete audit trail. You can reconstruct the state at any point in time.

CQRS (Command Query Responsibility Segregation)

Often used alongside Event Sourcing. The system uses separate models for reading and writing data. Write operations (Commands) go through the Event Sourcing pipeline. Read operations (Queries) hit a separate, optimized read database that is asynchronously updated by consuming events.

3. Advantages & Disadvantages

Advantages: Extreme loose coupling, independent scalability, high resilience (if one consumer is down, events queue up and are processed when it recovers), natural audit log.

Disadvantages: Eventual consistency (consumers don't update instantly), debugging is harder (tracing an event through 10 services), ensuring exactly-once processing is extremely difficult.