Event-Driven System: Mermaid Flowchart Diagram

About Source

An event-driven system is an architecture where services communicate by producing and consuming events — discrete records of something that happened — rather than calling each other directly through synchronous APIs.

What the diagram shows

The diagram centers on an Event Broker (such as Kafka, RabbitMQ, or AWS SNS/SQS). Three Producer services — Order Service, Payment Service, and Inventory Service — publish domain events to named Topics on the broker. The broker persists each event in its log and fans it out to every subscribed Consumer.

Three consumer groups are shown: the Notification Service subscribes to order.created and payment.confirmed events to trigger emails and push notifications; the Analytics Service subscribes to all topics for aggregation and reporting; and the Fulfillment Service subscribes to payment.confirmed to begin warehouse picking.

A Dead Letter Queue (DLQ) receives any events that fail processing after the maximum retry count, preventing poison messages from blocking the consumer indefinitely.

Why this matters

Event-driven architectures decouple producers from consumers: the Order Service does not need to know that a Notification Service exists — it simply publishes the event and moves on. This means new consumers can be added without changing the producer at all, enabling rapid extension of system behavior.

The main challenge is reasoning about ordering and exactly-once delivery. Most brokers provide at-least-once delivery, so consumers must be idempotent. For the CQRS pattern that uses events to synchronize read and write models, see CQRS Architecture. For background job patterns that consume from these queues, see Worker Queue Processing.

Frequently asked questions

An event-driven architecture is a design pattern where services communicate by publishing and consuming discrete event records — representing things that happened — through a central event broker, rather than calling each other synchronously via APIs.

Producer services publish domain events (e.g., `order.created`) to named topics on an event broker. The broker persists each event and fans it out to all consumer groups subscribed to that topic. Each consumer processes events independently at its own pace, with a Dead Letter Queue capturing events that fail after maximum retries.

Use event-driven architecture when you need to decouple producers from consumers, when multiple downstream services need to react to the same business event without the producer knowing about them, or when you need to process high-throughput streams asynchronously.

Common mistakes are assuming exactly-once delivery (most brokers offer at-least-once; consumers must be idempotent), ignoring event ordering requirements (partitioning strategy must guarantee order when needed), and not designing a schema evolution strategy — breaking consumer contracts when event fields change.

mermaid

flowchart LR
    OrderSvc[Order Service\nProducer] -->|order.created| Broker
    PaymentSvc[Payment Service\nProducer] -->|payment.confirmed| Broker
    InventorySvc[Inventory Service\nProducer] -->|stock.updated| Broker

    subgraph Broker[Event Broker\nKafka / RabbitMQ]
        T1[Topic: order.created]
        T2[Topic: payment.confirmed]
        T3[Topic: stock.updated]
        DLQ[Dead Letter Queue]
    end

    Broker --> NotifSvc[Notification Service\nConsumer]
    Broker --> AnalyticsSvc[Analytics Service\nConsumer]
    Broker --> FulfillSvc[Fulfillment Service\nConsumer]
    NotifSvc -->|Max retries exceeded| DLQ
    FulfillSvc -->|Max retries exceeded| DLQ

Event Driven System

What the diagram shows

Why this matters

Frequently asked questions