Event-Driven Architecture Overview

In event-driven architecture (EDA), services communicate by producing and consuming events rather than making direct API calls. When something happens in Service A (a user places an order), it publishes an event. Other services react to that event independently.

This approach enables loose coupling, high scalability, and resilience — but it introduces testing challenges that do not exist in synchronous systems: eventual consistency, event ordering, duplicate delivery, and complex failure modes.

Event Sourcing

Instead of storing the current state of an entity, event sourcing stores the sequence of events that led to that state.

Traditional approach (state-based):

Order #123: status=shipped, total=99.99, items=[A, B]

Event sourcing approach:

Event 1: OrderCreated { orderId: 123, items: [A, B] }
Event 2: PaymentReceived { orderId: 123, amount: 99.99 }
Event 3: OrderShipped { orderId: 123, trackingNumber: "ABC123" }

The current state is derived by replaying all events in order.

Testing Event Sourcing

Test 1: State reconstruction Given a sequence of events, verify that the aggregate’s current state is correct.

test('order state after creation and payment', () => {
  const events = [
    { type: 'OrderCreated', data: { orderId: '123', items: ['A', 'B'], total: 99.99 } },
    { type: 'PaymentReceived', data: { orderId: '123', amount: 99.99 } },
  ];

  const order = replayEvents(new Order(), events);

  expect(order.status).toBe('paid');
  expect(order.total).toBe(99.99);
  expect(order.items).toEqual(['A', 'B']);
});

Test 2: Event ordering matters Applying events in a different order should produce different states (or be rejected).

Test 3: Snapshot consistency If the system uses snapshots for performance, verify that state from snapshot + subsequent events equals state from replaying all events.

CQRS (Command Query Responsibility Segregation)

CQRS separates the write model (commands) from the read model (queries). Commands produce events that update the write store. A projector processes events to update read-optimized views.

Command → Write Model → Events → Projector → Read Model

Testing CQRS

Test the command side:

  • Sending a valid command produces the expected events.
  • Sending an invalid command is rejected with the correct error.
  • Commands enforce business rules (cannot ship an unpaid order).

Test the read side (projections):

  • After events are processed, the read model reflects the correct state.
  • Projections handle out-of-order events gracefully.
  • Projection rebuilds produce the same result as incremental updates.

Test the consistency gap: After a command succeeds, there is a delay before the read model updates. Test that:

  • The system handles this gap gracefully (no stale data errors).
  • The read model eventually catches up.

Saga Pattern

Sagas coordinate distributed transactions across services. There are two types:

Choreography-Based Saga

Each service listens for events and decides what to do next. No central coordinator.

OrderService: OrderCreated →
PaymentService: (listens) → PaymentProcessed →
InventoryService: (listens) → StockReserved →
ShippingService: (listens) → ShipmentCreated

Testing choreography:

  1. Trigger the initial event and verify the entire chain completes.
  2. Simulate a failure at each step and verify compensating events are triggered.
  3. Test timeout scenarios — what happens if a service does not respond?

Orchestration-Based Saga

A central orchestrator coordinates the saga steps.

SagaOrchestrator:
  Step 1: Command → PaymentService → Success/Failure
  Step 2: Command → InventoryService → Success/Failure
  Step 3: Command → ShippingService → Success/Failure
  On Failure: Execute compensating commands in reverse

Testing orchestration:

  1. Happy path: All steps succeed → saga completes.
  2. Failure at each step: Verify compensating actions execute correctly.
  3. Orchestrator crash/restart: Verify the saga resumes from where it left off.

Eventual Consistency Testing

The hardest part of testing event-driven systems is verifying that services eventually reach a consistent state.

Polling Pattern 

async function waitForConsistency(checkFn, timeout = 10000, interval = 500) {
  const start = Date.now();
  while (Date.now() - start < timeout) {
    const result = await checkFn();
    if (result) return result;
    await new Promise(resolve => setTimeout(resolve, interval));
  }
  throw new Error('Consistency timeout exceeded');
}

// Usage
test('order appears in read model after creation', async () => {
  await commandBus.send(new CreateOrderCommand({ items: ['A'] }));

  const order = await waitForConsistency(async () => {
    const result = await readModel.getOrder('123');
    return result?.status === 'created' ? result : null;
  });

  expect(order.items).toEqual(['A']);
});

Idempotency Testing

Verify that processing the same event twice produces the same result:

test('payment event is idempotent', async () => {
  const event = { type: 'PaymentReceived', orderId: '123', amount: 99.99 };

  await processEvent(event);
  await processEvent(event); // duplicate delivery

  const payments = await db.getPayments('123');
  expect(payments.length).toBe(1); // not 2
  expect(payments[0].amount).toBe(99.99);
});

Event Schema Evolution

As systems evolve, event schemas change. Consumers must handle both old and new event formats.

Test scenarios:

  1. Consumer receives an event with a new field it does not know about — does it ignore it gracefully?
  2. Consumer receives an event missing a field that was added later — does it use a default value?
  3. Consumer receives an event with a renamed field — does the system handle the migration?

Exercise: Event-Driven System Testing

Design and execute tests for an event-driven e-commerce system.

System Description

The system has four services communicating via events:

OrderService → PaymentService → InventoryService → NotificationService

Events:

  1. OrderCreated — published when a customer places an order
  2. PaymentProcessed — published when payment is confirmed
  3. PaymentFailed — published when payment is declined
  4. StockReserved — published when inventory is reserved
  5. StockInsufficient — published when inventory is unavailable
  6. OrderCancelled — compensating event when a step fails
  7. RefundInitiated — compensating event when payment needs reversal

Task 1: Happy Path Test

Write a test that verifies the complete flow:

  1. Publish OrderCreated with order details.
  2. Wait for PaymentProcessed to appear.
  3. Wait for StockReserved to appear.
  4. Verify the order status in the read model is “confirmed”.
  5. Verify inventory was decremented.

Task 2: Compensation Tests

For each failure point, verify the saga rolls back correctly:

Scenario A: Payment fails

  1. Publish OrderCreated.
  2. PaymentService publishes PaymentFailed.
  3. Verify OrderCancelled is published.
  4. Verify order status is “cancelled” in the read model.

Scenario B: Insufficient stock

  1. Publish OrderCreated.
  2. PaymentService publishes PaymentProcessed.
  3. InventoryService publishes StockInsufficient.
  4. Verify RefundInitiated is published (compensating for payment).
  5. Verify OrderCancelled is published.
  6. Verify order status is “cancelled” and payment is refunded.

Task 3: Idempotency Test

  1. Publish the same OrderCreated event twice (simulating duplicate delivery).
  2. Verify only one order is created in the database.
  3. Verify only one payment attempt is made.

Task 4: Event Ordering Test

  1. Publish PaymentProcessed before OrderCreated (out of order).
  2. Verify the system handles this gracefully — either buffering the payment event or rejecting it.

Task 5: Eventual Consistency Verification

  1. Create an order via the command endpoint.
  2. Immediately query the read model — it may not be updated yet.
  3. Poll the read model until the order appears (with a timeout).
  4. Record the consistency delay.
  5. Repeat 10 times and calculate average consistency delay.

Deliverables

  1. Test code for each scenario with assertions.
  2. A timing report showing eventual consistency delays.
  3. Documentation of any race conditions or edge cases discovered.