Event Driven Architecture - The Complete Guide

Explore what events are, their role as the cornerstone of event driven architecture, and how they evolved from other architectures.

Microservices architecture uses loosely coupled services in separate processes and lightweight, polyglot communication, replacing monolith and SOA. Focus on how services talk to each other in event-driven architecture.

Explore how services communicate via commands and queries in event driven architecture, including synchronous command execution, data retrieval, and knowing who handles each request.

Explore the limitations of command and query patterns, including performance, coupling, and scalability, and discover how events address these challenges.

Event driven architecture uses events to notify that something happened, with no response expected, and the calling service has no idea who handles the event, unlike commands or queries.

Explain the two event data types: complete events with all relevant data and pointer events that reference the database, and when to use each for autonomous versus up-to-date processing.

Explore how event driven architecture (EDA) uses events as the communication method between services, introducing the producer, channel, and consumer as the three core components.

Explore how the producer, or publisher, sends events to a channel in event-driven architecture, with examples like a new customer added or sold-out item via the channel.

Understand the channel, the central element that distributes events to consumers via a topic or fan-out queue.

The consumer receives and processes events from producers via a channel, using push or pull delivery as dictated by the channel implementation, and may send an acknowledgement (EC).

Discover the advantages of event driven architecture: asynchronous communication that prevents bottlenecks, with producers, channels, topics, and queues enabling loose coupling and scalability.

Explain how event driven architecture and pub/sub relate, defining pub/sub components (publisher, broker, subscriber) and comparing them with producer, channel, and consumer, while noting rest APIs for synchronous queries.

Explore ordering in event driven architecture and why pub-sub may not guarantee message order. Choose channels that support ordering, such as RabbitMQ, to mitigate latency and performance effects.

Explore orchestration and choreography in event driven architecture, where a central orchestrator guides event flow like a state machine and autonomous services publish and react to events.

Explore event sourcing and security as a popular pattern for handling data through events, learn how events can be building blocks of data beyond services, and contrast with traditional databases.

Traditional databases capture only the current state of an entity, hiding historical data such as prior roles or name changes; event sourcing records the events that drive state changes.

Event sourcing stores every change as an event in an event store, capturing inserts rather than updates or deletes, and enables replaying events to derive the current state.

Explore CQRS by separating commands and queries into two databases—a command store using an event store and a traditional query store—synchronized by a central mechanism.

Explore when to use event sourcing and cqrs, with security considerations for regulatory or financial and healthcare data, unfeasible event replay, and performance-critical inserts or queries, versus a traditional database.

Explore when to use event driven architecture, weighing setup, channel configuration, and complex logging and monitoring, and review scenarios to decide its fit.

Master scalability in event driven architecture by adding new consumers without modifying the producer or channel to handle fluctuating load, enabling seamless scale-out.

Explore why event driven architecture is inherently asynchronous and how to identify synchronous interactions in inter-service communication. Analyze scenarios like payment instructions and logging to determine when it fits.

Ensure a reliable and fast network to handle the heavy traffic and the many points where networking participates in Ida's architecture, otherwise performance will be slow.

Avoid EDA for small systems with few services due to overhead from components like the channel. Synchronous information systems serving end-user queries are usually not a good fit for EDA.

Explore stateless and stateful patterns in event driven architecture, focusing on consumer behavior and choosing the right pattern for your scenario, independent of producer or channel.

Stateless EDA treats each event as an autonomous unit with outcomes independent of past or future events, allowing any consumer to process it with the same result.

Explore how stateful event-driven architecture tracks past events to support time-window calculations and aggregations. Route related events to the same consumer to ensure consistent, chain-based results.

Explore the problems of stateful event-driven architecture, including load balancing and scalability, where state lives in a consumer, limiting scaling; use stateless design unless business requirements force stateful.

Explore what event streaming is and how it relates to event driven architecture, noting it isn't the same but shares event-based patterns and uses events heavily.

Understand how event streaming publishes and retains a stream of events for past retrieval, enabling consumers to pull relevant events and use the engine as a single source of truth.

Compare event streaming and event-driven architecture by highlighting external event origins, retention and high-load handling for telemetry streams, versus internal system events that are not retained and are selectively handled.

Identify when to use event streaming, such as external event streams like sensor data, event retention for future use, and handling high load, by using specialized tools like Apache Kafka.

Explore how logging and monitoring provide a holistic view of an event driven architecture, and learn why implementing them in distributed systems is particularly challenging.

In event driven architecture, distributed, loosely coupled components hinder unified, chronologically ordered logs due to different formats, destinations, and unsynced timestamps. The remedy starts with correlation ID.

Attach a unique correlation ID to every transaction to trace logs across producers, channels, and consumers in a distributed event-driven system, enabling easy log aggregation and holistic visibility.

Explore the central logging engine that aggregates all log records, unifies formats, and provides analytics and alerts within an event driven architecture using Elastic Stack.

Log all relevant events to reflect system behavior, not just errors; capture the trigger, event contents, correlation ids, and the receive and handling steps to enable replay and performance analysis.

Explore advanced topics in event driven architecture, including mixing IIDA with request response, synchronous idea, events as source of truth and the saga pattern, and front-end EDA.

Mix EDA with request/response by using a REST API to receive commands, emit events, and return HTTP 201 to acknowledge receipt while the event flows asynchronously to consumers.

Explore synchronous event-driven architecture, where a wrapper exposes a rest api to hold the producer and channel until a return event confirms status, enabling a simulated synchronous workflow.

learn how events serve as the source of truth in event driven architecture, using databases or retained channels like kafka as the truth, with kql queries for complex access.

Explore the saga pattern within event-driven architecture, solving distributed transactions where two-phase commit struggles, via chained service-scoped transactions and compensating actions triggered by events through a central channel.

Explore front end event driven architecture, where micro front ends connect independent components via browser events and push notifications stream server events to clients using SignalR, Socket.IO, or gRPC.

Learn how to implement event-driven architecture by selecting the events approach and designing the channel, the producer, and the consumer.

Choose the events approach by deciding whether to retain events with a configurable retention period for streaming and source-of-truth use, or publish without storage for in-system events.

Compare retained and non-retained event approaches and implement the channel with publishers or messaging engines such as rabbit or Kafka, including Azure Event Grid, webhooks, and HTTP push.

Implement the producer by connecting to the channel with platform libraries (RabbitMQ or SignalR), configuring the hub, and defining functions to send messages; optionally group messages to filter delivery.

Implement the consumer across platforms with platform-specific RabbitMQ client libraries, register via the rest API, and expose a rest API to receive webhook calls, illustrating event driven architecture.