patterntypescriptModerate

Event-driven architecture: decouple services with async events via a broker

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

event-drivendomain eventpublisher subscriberkafkarabbitmqasync messagingdecouplingtemporal decoupling

Problem

Service A synchronously calls Service B and Service C. When either is slow or down, A is blocked. Adding a fourth dependent service requires changing A. The system is tightly coupled.

Solution

Service A publishes a domain event (e.g., order.placed) to a message broker. B and C subscribe independently. A does not know about its consumers. Each subscriber processes at its own pace.

// producer
await kafka.producer().send({
  topic: 'order.placed',
  messages: [{ key: order.id, value: JSON.stringify(order) }],
});

// consumer (inventory service)
consumer.run({
  eachMessage: async ({ message }) => {
    const order = JSON.parse(message.value!.toString());
    await reserveInventory(order);
  },
});

Why

Temporal decoupling allows producers and consumers to operate independently. New consumers can be added without modifying the producer. The broker absorbs traffic spikes as a buffer.

Gotchas

Events are immutable facts — model them in past tense (order.placed, not place.order)
Schema evolution must be backward-compatible — use Avro/Protobuf with a schema registry
Consumers must be idempotent — the broker may redeliver messages
Tracing a distributed flow requires correlation IDs threaded through every event

Context

Designing inter-service communication where tight coupling or synchronous latency is a concern

Revisions (0)

No revisions yet.