Instead of direct HTTP calls between microservices (which causes temporal coupling), Event-Driven Architectures (EDA) rely on services publishing events to a central broker (like Kafka) and other services reacting to them asynchronously.


Module 1: Brokers vs. Queues

Message Queues (like RabbitMQ or SQS) are typically point-to-point and the message is deleted once consumed. Event Brokers (like Kafka or Kinesis) act as an immutable, append-only log where multiple consumers can read the same event stream.

Benefits of the Event Log

  • Replayability: If a new service is added, it can read the entire history of events from the beginning.
  • High Throughput: Kafka can handle millions of messages per second by distributing partitions across brokers.
  • Decoupling: The publisher doesn't care who is listening.

Module 2: Event Sourcing & CQRS

In Event Sourcing, the database doesn't store current state. It stores a sequence of events. The current state is derived by projecting these events. This pairs perfectly with Command Query Responsibility Segregation (CQRS), where the read models and write models are completely separate.

EventSourcing.jsjavascript
function reduceAccountState(events) {
  let balance = 0;
  for(let event of events) {
    if (event.type === 'DEPOSIT') balance += event.amount;
    if (event.type === 'WITHDRAWAL') balance -= event.amount;
  }
  return balance;
}

Module 3: Idempotency & Delivery Guarantees

In distributed systems, networks drop packets. A broker will usually provide At-Least-Once delivery, meaning a consumer might receive the same event twice.