Practice : Event-Driven Architecture (EDA)

Purpose and Strategic Importance

Event-Driven Architecture (EDA) is a design paradigm where services communicate by producing and reacting to events. Rather than invoking each other directly, systems react to state changes signalled through messages - allowing for greater decoupling, resilience, and real-time responsiveness.

EDA is foundational for scalable, loosely coupled, and asynchronous systems. It enables autonomy between services, unlocks real-time analytics, and supports high-throughput event processing for modern digital platforms.

Description of the Practice

  • Events are messages that represent a change in state (e.g. "order placed", "payment failed").
  • Systems are split into event producers and consumers - communicating through topics or message brokers.
  • Common tooling includes Kafka, AWS SNS/SQS, RabbitMQ, NATS, and Azure Event Grid.
  • Event schemas (contracts) are versioned and shared across teams for consistency and validation.
  • EDA supports patterns like pub/sub, event sourcing, CQRS, and sagas.

How to Practise It (Playbook)

1. Getting Started

  • Identify use cases where decoupling and responsiveness are essential (e.g. workflows, audit trails, real-time notifications).
  • Start with a simple event - define its schema, producer, and initial consumers.
  • Choose a messaging platform and set up basic observability and dead-letter handling.
  • Validate that event processing is idempotent and fault-tolerant.

2. Scaling and Maturing

  • Establish a schema registry and versioning strategy to evolve events safely.
  • Implement consumer groups, retries, and circuit breakers for reliability.
  • Adopt patterns like event choreography and orchestration for complex flows.
  • Track end-to-end event journeys through observability tools (e.g. distributed tracing, correlation IDs).
  • Evaluate use of streaming technologies for high-volume or low-latency workloads.

3. Team Behaviours to Encourage

  • Treat events as first-class citizens - modelled, tested, and versioned.
  • Share ownership of event contracts across teams.
  • Use event logs to support debugging, analytics, and root cause analysis.
  • Foster shared understanding of event flows via diagrams and collaboration.

4. Watch Out For…

  • Event sprawl with unclear ownership or undocumented schemas.
  • Overcomplication - not every interaction needs to be asynchronous.
  • Tight coupling through synchronous fallbacks or schema breakages.
  • Difficulty troubleshooting without proper logging and traceability.

5. Signals of Success

  • Services evolve independently while maintaining consistent event flows.
  • Real-time features are reliable and scalable.
  • Event schemas are discoverable, documented, and respected.
  • Failures are isolated, recoverable, and visible through observability.
  • Teams think in terms of event impact, not just synchronous interactions.