Event Choreography for Microservices

Overview

In event choreography, there is no central coordinator. Each service publishes domain events and subscribes to the events it cares about, reacting locally. A business process emerges from the chain of reactions rather than being directed from one place. This maximizes decoupling: services know about events, not about each other.

Use choreography when teams must move independently, when workflows are relatively linear, and when you value loose coupling over centralized visibility. It complements domain-driven design, where each bounded context owns its events.

Components

• NATS / JetStream: the lightweight, high-throughput event transport with durable streams.
• Knative Eventing: routes and delivers CloudEvents to subscribing services on Kubernetes.
• Microservices: bounded-context services that publish and consume events.
• PostgreSQL: per-service datastore following database-per-service.
• Schema registry: governs event schemas and compatibility.
• Jaeger: distributed tracing to follow a process across service hops.
• Prometheus: per-service and per-event metrics.

Data Flow

A service completes a local transaction and publishes a domain event in CloudEvents format. Knative Eventing delivers it to all subscribers. Each subscriber performs its own local transaction and may publish further events, continuing the chain. For example, an order-placed event triggers inventory reservation, which emits inventory-reserved, which triggers payment, and so on, all without a controller.

Scaling and Resilience

Services scale independently as Kubernetes deployments. NATS JetStream provides durable, replayable streams so consumers recover after downtime. Each service implements idempotent consumers and outbox-pattern publishing to avoid lost or duplicated events. Compensating events handle failures saga-style. Tracing stitches the distributed flow back together for debugging.

Security

NATS enforces TLS and account-scoped credentials per service. The schema registry blocks incompatible event changes. CloudEvents carry no secrets; sensitive data is referenced by ID and fetched over authenticated APIs. Network policies restrict event delivery to authorized subscribers, and least-privilege applies to each service's datastore.

Trade-offs and Alternatives

Choreography's weakness is visibility: no single place describes the whole workflow, making complex processes hard to understand and debug, hence the need for strong tracing. For workflows with many branches, compensations, or strict ordering, orchestration (a central saga coordinator) is clearer. Choreography suits simpler, linear flows and teams that prize autonomy. The two patterns are often mixed within one system.