Event Driven Architecture

What is Event-Driven Architecture (EDA)?

• EDA (Event-Driven Architecture) is a software approach built on business events, not just software or infrastructure triggers.
• Business events (e.g., “order created”, “delivery completed”) are central; systems react to these rather than technical notifications.
• This enables clear communication between business and development, aligning system design with business language and processes.
• Events in EDA are immutable—representing facts that have already happened.
• Systems using EDA only operate when there is work to do, making them more reactive and efficient.

Core Advantages of EDA

• Facilitates communication between technical and business teams using a common event language.
• Optimizes architectures for the rate of change and future extensibility.
• Reduces friction in adding new features by tapping into existing event streams.
• Promotes decoupling, making it easier to evolve and extend distributed systems.

Key Concepts and Patterns

• Events are immutable and defined by business actions, not technical events.
• Metadata and versioning are crucial for managing change—every event should include information like event identifiers, trace IDs, and version numbers.
• Versioning enables parallel support for old and new event schemas during migrations, reducing the risk of breaking changes.
• Schema management is critical; trivial changes in event structure can have large impacts, particularly in decoupled producer/consumer setups.
• The metadata-data pattern is recommended: core metadata follows a standard schema, while event-specific data varies per event.

Architectural Trade-offs: Fat vs. Sparse Events

• Sparse (notification) events carry minimal information, often just an ID, requiring consumers to request more data separately.
• Fat (event-carried state transfer) events embed all relevant details within the event itself, reducing the need for consumers to fetch more data.
• Fat events increase convenience but also schema-level coupling and the potential complexity of breaking changes.
• Sparse events minimize coupling, but may increase system chatter and complexity in retrieving associated state.
• The choice between fat and sparse events depends on the event’s nature and consumer requirements.

Challenges and Considerations

• Adopting EDA requires a mindset shift, especially for those used to synchronous or method-based designs.
• Schema management and evolution are non-trivial due to decoupled services and risk of unintentional breaking changes.
• Change is inevitable—future requirements and breaking changes should be anticipated with robust versioning and event design.
• Design decisions around event structure significantly impact extensibility, maintainability, and system flexibility.