Arquitectura orientada a eventos

Welcome to Event-Driven Architecture (EDA)! This powerful design pattern helps build flexible and scalable systems.

In EDA, services communicate indirectly by emitting and reacting to events rather than making direct requests.

EDA offers several key advantages for modern applications:

• Loose Coupling: Services don't need to know about each other's internal workings.
• Scalability: Easier to add new consumers without changing producers.
• Resilience: If one service fails, others can often continue processing.
• Responsiveness: Actions can trigger multiple parallel reactions.

EDA revolves around three main components:

• Events: Notifications that something important has happened.
• Event Producers: Services that generate and publish events.
• Event Consumers: Services that subscribe to and react to events.

Think of it like a newspaper: the editor (producer) publishes news (events), and readers (consumers) pick up what interests them.

An event is a record of a significant occurrence or 'fact' within your system. It's immutable, meaning it cannot be changed once created.

Events typically contain data about what happened, but not how to react to it. They are past-tense facts.

Here's a simple example of what an event's data might look like. It describes a 'User Registered' event:

{
  "eventType": "UserRegistered",
  "payload": {
    "userId": "uuid-1234",
    "email": "user@example.com",
    "timestamp": "2023-10-27T10:00:00Z"
  }
}

This event simply states a fact: a user was registered at a specific time, with specific details.

An Event Producer is a service that performs an action and then publishes an event to signal that action has occurred.

It doesn't care which other services (if any) will listen to or react to this event. This 'fire and forget' approach leads to loose coupling.

An Event Consumer is a service that subscribes to specific event types it's interested in.

When an event it's subscribed to is published, the consumer receives it and performs its own specific actions in response.

For example, an email service might consume a 'UserRegistered' event to send a welcome email.

Often, an Event Broker (or Message Queue) sits between producers and consumers.

It acts as an intermediary, reliably receiving events from producers and delivering them to interested consumers. This ensures events aren't lost and enables scaling.

This simple Java example demonstrates the core idea of emitting and consuming events within a single application. Imagine different parts of your system as these listeners!

You've now got a grasp of Event-Driven Architecture!

• EDA uses events for indirect communication.
• It promotes loose coupling, scalability, and resilience.
• Key roles are Event Producers, Event Consumers, and often an Event Broker.

This pattern is fundamental for building robust, distributed systems, especially microservices.