Content Role: pillar

Event-Driven Architecture: Decoupling Microservices

Event sourcing and CQRS patterns with Kafka and EventBridge

Microservices architectures promise scalability and independent deployments, but tight coupling between services creates bottlenecks that negate these benefits. When Service A directly calls Service B, which calls Service C, you've built a distributed monolith with cascading failures and deployment dependencies. Event-driven architecture patterns solve this problem by introducing asynchronous communication through events, allowing services to operate independently while maintaining system coherence.

The Coupling Problem in Microservices

Traditional request-response patterns create several critical issues:

Temporal coupling: Services must be available simultaneously. If the payment service is down, the order service cannot complete its operation, even though order creation and payment processing are conceptually separate concerns.

Implementation coupling: Service A needs to know Service B's API contract, deployment location, and authentication requirements. Changes to Service B ripple through all consumers.

Cascading failures: A single slow or failing service degrades the entire call chain. Response times compound, and timeouts propagate upstream.

Deployment coordination: Updating Service B requires coordinating with all upstream services to handle API changes, making independent deployments impossible.

These problems intensify as systems scale. A system with 10 services might have 45 potential direct connections. At 50 services, that number becomes 1,225.

Event-Driven Architecture Fundamentals

Event-driven architecture patterns decouple services through asynchronous message passing. Instead of Service A calling Service B, Service A publishes an event describing what happened. Service B subscribes to relevant events and reacts independently.

Core concepts:

• Events: Immutable facts about state changes (OrderPlaced, PaymentProcessed)
• Producers: Services that publish events when state changes occur
• Consumers: Services that subscribe to and process events
• Event bus: Infrastructure that routes events from producers to consumers

This inversion of control fundamentally changes system dynamics. Producers don't know or care who consumes their events. Consumers process events at their own pace. Services can be added or removed without modifying existing components.

Event Sourcing Pattern

Event sourcing stores state changes as a sequence of events rather than current state snapshots. Instead of updating a database record, you append events to an immutable log. Current state is derived by replaying events.

Implementation with TypeScript and Kafka

// Domain events
interface DomainEvent {
  eventId: string;
  aggregateId: string;
  eventType: string;
  timestamp: Date;
  version: number;
}

interface OrderCreated extends DomainEvent {
  eventType: 'OrderCreated';
  customerId: string;
  items: Array<{ productId: string; quantity: number; price: number }>;
  totalAmount: number;
}

interface OrderShipped extends DomainEvent {
  eventType: 'OrderShipped';
  trackingNumber: string;
  carrier: string;
}

// Event store implementation
class EventStore {
  private kafka: Kafka;
  private producer: Producer;

  constructor(brokers: string[]) {
    this.kafka = new Kafka({ brokers });
    this.producer = this.kafka.producer();
  }

  async append(event: DomainEvent): Promise<void> {
    await this.producer.send({
      topic: `events-${event.aggregateId}`,
      messages: [{
        key: event.aggregateId,
        value: JSON.stringify(event),
        headers: {
          eventType: event.eventType,
          version: event.version.toString()
        }
      }]
    });
  }

  async getEvents(aggregateId: string): Promise<DomainEvent[]> {
    const consumer = this.kafka.consumer({ groupId: `replay-${Date.now()}` });
    const events: DomainEvent[] = [];

    await consumer.subscribe({ topic: `events-${aggregateId}`, fromBeginning: true });

    await consumer.run({
      eachMessage: async ({ message }) => {
        events.push(JSON.parse(message.value!.toString()));
      }
    });

    return events;
  }
}

// Aggregate reconstruction
class Order {
  id: string;
  customerId: string;
  items: Array<{ productId: string; quantity: number; price: number }> = [];
  status: 'created' | 'shipped' | 'delivered' = 'created';
  version: number = 0;

  static async load(eventStore: EventStore, orderId: string): Promise<Order> {
    const events = await eventStore.getEvents(orderId);
    const order = new Order();

    events.forEach(event => order.apply(event));
    return order;
  }

  private apply(event: DomainEvent): void {
    switch (event.eventType) {
      case 'OrderCreated':
        const created = event as OrderCreated;
        this.id = created.aggregateId;
        this.customerId = created.customerId;
        this.items = created.items;
        break;
      case 'OrderShipped':
        this.status = 'shipped';
        break;
    }
    this.version = event.version;
  }
}

Event sourcing provides complete audit trails, temporal queries (state at any point in time), and the ability to fix bugs by replaying events with corrected logic.

CQRS Pattern

Command Query Responsibility Segregation separates read and write models. Commands modify state through events. Queries read from optimized projections built by consuming events.

CQRS with EventBridge

// Command handler
class OrderCommandHandler {
  constructor(
    private eventStore: EventStore,
    private eventBridge: EventBridgeClient
  ) {}

  async createOrder(command: CreateOrderCommand): Promise<string> {
    const orderId = generateId();
    const event: OrderCreated = {
      eventId: generateId(),
      aggregateId: orderId,
      eventType: 'OrderCreated',
      timestamp: new Date(),
      version: 1,
      customerId: command.customerId,
      items: command.items,
      totalAmount: command.items.reduce((sum, item) => sum + item.price * item.quantity, 0)
    };

    await this.eventStore.append(event);

    // Publish to EventBridge for other services
    await this.eventBridge.send(new PutEventsCommand({
      Entries: [{
        Source: 'order.service',
        DetailType: 'OrderCreated',
        Detail: JSON.stringify(event),
        EventBusName: 'application-events'
      }]
    }));

    return orderId;
  }
}

// Query model projection
class OrderQueryModel {
  constructor(private dynamoDB: DynamoDBClient) {}

  async handleOrderCreated(event: OrderCreated): Promise<void> {
    await this.dynamoDB.send(new PutItemCommand({
      TableName: 'OrderReadModel',
      Item: {
        orderId: { S: event.aggregateId },
        customerId: { S: event.customerId },
        totalAmount: { N: event.totalAmount.toString() },
        status: { S: 'created' },
        createdAt: { S: event.timestamp.toISOString() },
        itemCount: { N: event.items.length.toString() }
      }
    }));
  }

  async getOrdersByCustomer(customerId: string): Promise<OrderSummary[]> {
    const result = await this.dynamoDB.send(new QueryCommand({
      TableName: 'OrderReadModel',
      IndexName: 'CustomerIndex',
      KeyConditionExpression: 'customerId = :customerId',
      ExpressionAttributeValues: {
        ':customerId': { S: customerId }
      }
    }));

    return result.Items?.map(item => ({
      orderId: item.orderId.S!,
      totalAmount: parseFloat(item.totalAmount.N!),
      status: item.status.S!,
      createdAt: new Date(item.createdAt.S!)
    })) || [];
  }
}

CQRS enables independent scaling of read and write workloads, optimized query models for specific use cases, and flexibility to use different storage technologies for commands and queries.

Common Pitfalls

Event schema evolution: Events are immutable and long-lived. Schema changes require versioning strategies. Use semantic versioning in event types and maintain backward compatibility. Never delete fields; add new optional fields instead.

Eventual consistency: Consumers process events asynchronously. The read model lags behind writes. Design UIs to handle this gracefully—show "processing" states rather than immediately reflecting changes.

Event ordering: Distributed systems don't guarantee global ordering. Use partition keys (aggregate IDs) to ensure ordering within an aggregate. Don't assume cross-aggregate ordering.

Duplicate events: Network failures and retries cause duplicate delivery. Make consumers idempotent by tracking processed event IDs or designing operations to be naturally idempotent.

Event granularity: Too fine-grained events create noise and coupling. Too coarse-grained events miss important state changes. Model events around business-meaningful state transitions.

Missing events: Lost events corrupt state. Use persistent message brokers with replication. Implement monitoring to detect gaps in event sequences.

Best Practices Checklist

• [ ] Use domain events that reflect business language, not technical operations
• [ ] Include correlation IDs to trace requests across service boundaries
• [ ] Implement event versioning from day one
• [ ] Make all event consumers idempotent
• [ ] Use dead letter queues for failed event processing
• [ ] Monitor event lag and processing rates
• [ ] Implement event replay capabilities for recovery and debugging
• [ ] Store events with sufficient context to be self-describing
• [ ] Use schema registries (Confluent Schema Registry, AWS Glue) for validation
• [ ] Implement circuit breakers for external dependencies in event handlers
• [ ] Design compensating transactions for distributed saga patterns
• [ ] Test event handlers in isolation with synthetic events

FAQ

Q: When should I use event-driven architecture instead of synchronous APIs?

Use event-driven patterns when services need loose coupling, when operations are naturally asynchronous, or when you need to notify multiple consumers of state changes. Stick with synchronous APIs for queries requiring immediate consistency or when request-response semantics are clearer.

Q: How do I handle transactions across multiple services?

Use the saga pattern with choreography (services react to events) or orchestration (a coordinator manages the workflow). Implement compensating transactions to roll back on failures. Accept eventual consistency rather than distributed transactions.

Q: What's the difference between Kafka and EventBridge?

Kafka is a high-throughput event streaming platform optimized for ordered, persistent logs. EventBridge is a serverless event bus with built-in routing, schema discovery, and AWS service integrations. Use Kafka for event sourcing and high-volume streams. Use EventBridge for service integration and lower-volume event routing.

Q: How do I query data in an event-sourced system?

Build read models (projections) by consuming events and populating optimized query databases. Use CQRS to separate write operations (commands) from read operations (queries). Maintain multiple projections for different query patterns.

Q: How do I handle event schema changes without breaking consumers?

Version your events explicitly. Add new optional fields rather than modifying existing ones. Maintain multiple event versions during transitions. Use schema registries to validate compatibility. Consider using Protocol Buffers or Avro for schema evolution support.

Q: What happens if event processing fails?

Implement retry logic with exponential backoff. Use dead letter queues to capture events that fail after multiple retries. Monitor dead letter queues and implement alerting. Design compensating actions to handle partial failures in sagas.

Q: How do I test event-driven systems?

Test event handlers in isolation with synthetic events. Use contract testing to verify event schemas between producers and consumers. Implement integration tests that publish events and verify projections. Use chaos engineering to test failure scenarios and recovery mechanisms.