What is choreography?

Choreography is a way for different software components or services to work together by each one knowing what to do and when, without a central controller telling them what to do. Think of it like a dance where each dancer follows a shared script, so the whole performance runs smoothly.

Let's break it down

  • Independent services: Each micro‑service or component runs on its own.
  • Shared contract: They agree on events, messages, or APIs they will use.
  • Event‑driven: When something happens (e.g., an order is placed), a service publishes an event.
  • Reacting services: Other services listen for that event and act accordingly (e.g., inventory checks, payment processing).
  • No central boss: There is no single “orchestrator” that decides the order; the flow emerges from the events themselves.

Why does it matter?

  • Scalability: Services can be added, removed, or scaled independently because they only need to understand the shared events.
  • Resilience: If one service fails, others can keep working or retry later, reducing a single point of failure.
  • Flexibility: Changing business logic often only requires updating the events or the listeners, not rewriting a central workflow engine.
  • Loose coupling: Services stay loosely connected, making the whole system easier to maintain and evolve.

Where is it used?

  • Micro‑service architectures for e‑commerce, banking, or streaming platforms.
  • Event‑driven systems like Kafka, RabbitMQ, or AWS EventBridge.
  • Serverless applications where functions react to events.
  • IoT ecosystems where devices publish sensor data and other components react.
  • Business process management tools that support choreography diagrams.

Good things about it

  • Reduces the need for a heavyweight central controller.
  • Improves system agility and speeds up development cycles.
  • Enhances fault tolerance because services operate independently.
  • Makes it easier to integrate third‑party services that can simply listen to or emit events.
  • Aligns well with modern cloud‑native and serverless platforms.

Not-so-good things

  • Complex debugging: Tracing a request across many asynchronous events can be hard.
  • Hidden dependencies: If services rely on events that change, it may cause subtle bugs.
  • Event versioning: Managing changes to event schemas requires careful planning.
  • Potential for race conditions: Without a central order, services might act on events in an unexpected sequence.
  • Learning curve: Teams need to understand event‑driven design and proper tooling.