Picture a school play. There are two ways to run it backstage.

Way one: a director stands in the wings holding the script. She points at each actor and says “you, walk in now,” “you, say your line now,” “you, cut the lights now.” Every actor waits for her signal. Nobody moves unless she tells them to.

Way two: there is no director backstage at all. Every actor has memorised the whole play. When actor A finishes a line, actor B knows — just from hearing that line — that it’s their turn. Actor C sees actor B walk on stage and knows that’s their cue to start playing music. Nobody is in charge. Everyone reacts to what just happened around them.

The first approach is called orchestration. The second is called service choreography. This tutorial is about the second one — how independent pieces of software work together, in sync, without a boss issuing instructions at every step.

1.1 Where did this idea come from?

Service choreography is not brand new — the vocabulary comes straight from real-world dance and theatre, applied to software design starting in the early-to-mid 2000s, when companies began breaking large “monolithic” applications (one giant program that does everything) into smaller, independent programs called services.

The term became formalised around the same era as Service-Oriented Architecture (SOA), in specifications like WS-CDL (Web Services Choreography Description Language) in the mid-2000s. It later became far more practical and popular with the rise of microservices (roughly 2011–2015 onward), when companies like Netflix, Amazon, and Uber needed hundreds — sometimes thousands — of small services to cooperate without creating a single fragile “brain” that everything depended on.

1.2 Why does this matter today?

Modern applications — think of a food delivery app, an online store, or a ride-sharing app — are built from dozens or hundreds of small services: an Order Service, a Payment Service, an Inventory Service, a Notification Service, a Delivery Service, and so on. These services need to cooperate to complete one business goal (like “deliver this pizza”), but keeping them cooperating without a fragile central controller is a real engineering challenge. Service choreography is one of the two major answers to that challenge.

2.1 Step 1 — one giant program (the monolith)

In the beginning, most applications were built as one big program — a monolith. All the logic for orders, payments, inventory, and shipping lived inside the same codebase, running as a single unit.

2.2 Step 2 — breaking it apart (microservices)

To fix this, engineers split the monolith into small, independent services — one team owns Orders, another owns Payments, another owns Inventory. Each service has its own codebase, its own database, and can be deployed independently. This is called a microservices architecture.

But now a new problem appears: how do these separate services talk to each other to finish one task?

2.3 Step 3 — two answers: orchestration and choreography

There are exactly two broad strategies to solve this “who talks to whom, and in what order” problem:

• Orchestration — a central controller (an “orchestrator”) calls each service directly, one after another, like a recipe being followed step by step.
• Choreography — there is no central controller. Each service announces “something happened” (an event), and other services listen for events they care about and react on their own.

This tutorial focuses on choreography — but we will compare it to orchestration constantly, because understanding one deeply requires understanding the other.

3.1 Service

What it is. A small, independent piece of software that does one job well (for example, handling payments) and exposes that capability to others.

Why it exists. So teams can build, test, and deploy pieces of a big application separately, without stepping on each other’s toes.

Simple analogy. A specialist worker in a factory — one person only tightens bolts, another only paints, another only checks quality.

3.2 Event

What it is. A fact that “something happened” — stated in the past tense. For example: OrderPlaced, PaymentCompleted, StockReserved.

Why it exists. Events let a service announce facts without needing to know who is listening, or caring what they will do about it.

Simple analogy. A school bell ringing. The bell does not command anyone. It just announces “class is over.” Students, teachers, and cafeteria staff each react in their own way — nobody is told individually.

3.3 Event Bus / Message Broker

What it is. A piece of infrastructure that carries events from the service that published them to every service that wants to receive them. Popular real tools: Apache Kafka, RabbitMQ, AWS EventBridge, Google Pub/Sub, Azure Service Bus.

Why it exists. Without it, every service would need to know the network address of every other service — a tangled mess as the system grows.

Simple analogy. A postal system. You drop a letter in a mailbox (publish); you don’t personally deliver it to the reader’s door. The postal system (broker) figures out delivery.

3.4 Publish / Subscribe (Pub/Sub)

What it is. A messaging pattern where publishers send events to named “topics” or “channels,” and subscribers listen to the topics they care about.

Why it exists. It decouples the sender from the receiver — the sender never needs a list of receivers.

Simple analogy. A YouTube channel. The creator (publisher) uploads a video to their channel. They don’t email every subscriber directly — YouTube (the broker) notifies whoever subscribed.

3.5 Autonomy

What it is. Each service decides, on its own, how to react to an event — no external party forces its behaviour.

Why it exists. Autonomy is what allows teams to change their service’s internal logic without asking permission from other teams.

Simple analogy. When the school bell rings, the cafeteria staff decides on their own how to prepare lunch. The bell does not dictate the recipe.

3.6 Decoupling

What it is. Reducing the direct dependencies between two pieces of software, so a change in one does not force a change in the other.

Why it exists. Tightly coupled systems become fragile — one broken piece can crash everything connected to it.

Simple analogy. Cars on a highway are not welded together. Each drives independently, following shared rules (traffic lights, lanes) rather than being physically tied to the car in front.

3.7 Saga Pattern

What it is. A way to manage a business transaction that spans multiple services, using a sequence of local transactions, each triggered by the completion of the previous one, with defined “compensating” actions if something fails.

Why it exists. In a single database, you can use a fast, all-or-nothing (ACID) transaction. Across separate services with separate databases, you cannot — so Sagas simulate the same all-or-nothing feeling using events and rollback logic.

Simple analogy. Planning a trip with flights, hotels, and a rental car booked separately. If the hotel booking fails after you have already booked the flight, you cancel the flight (a compensating action) rather than being stuck.

3.8 Idempotency

What it is. A property where performing the same operation multiple times has the same effect as doing it once.

Why it exists. In distributed systems, messages can be delivered more than once (duplicate delivery). If “charge $50” isn’t idempotent, a duplicate event could charge the customer twice.

Simple analogy. Pressing an elevator button five times does not call the elevator five times. One request is enough — pressing again changes nothing.

3.9 Event Sourcing

What it is. Storing every change to data as a sequence of events, instead of just storing the current state. The current state is rebuilt by replaying events.

Why it exists. It gives a complete history/audit trail and lets you rebuild past states, which is very valuable in choreography-heavy systems that already think in “events.”

Simple analogy. A bank statement. Instead of only showing your current balance, it lists every deposit and withdrawal — you can always recompute the balance from the full history.

3.10 Eventual Consistency

What it is. A guarantee that, given enough time (usually milliseconds to seconds) and no new updates, all parts of a distributed system will reflect the same, correct data — even though at any single instant they might briefly disagree.

Why it exists. Choreographed systems update different services at different, independent moments. There is a small window of “some services know, some don’t yet” before everything settles.

Simple analogy. Gossip in a small town. When something happens, not everyone learns about it in the same second — but within a day, everyone knows. The information “eventually” spreads to everyone.

3.11 Command vs Event

What it is. A command is a request telling something to happen in the future (“ChargeCustomer”). An event is a statement that something has already happened in the past (“CustomerCharged”). Choreography is built almost entirely on events, not commands, because commands imply the sender knows exactly who should act — which reintroduces the coupling choreography tries to avoid.

Why it exists. Naming events in the past tense keeps every service free to interpret the fact however it wants, instead of being told exactly what to do.

3.12 Topic vs Queue

What it is. A topic (used in publish/subscribe) delivers a copy of each event to every subscriber. A queue delivers each individual message to only one consumer, even if many consumers are listening — used for spreading out work rather than broadcasting facts.

Why it exists. Choreography typically needs topics, because many different services (Payment, Inventory, Analytics) all need to know the same fact independently. Queues are more useful for distributing a large pile of identical jobs among worker instances of the same service.

3.13 Choreography vs Simple Pub/Sub

It is worth clarifying a subtle point: not every pub/sub system is “choreography.” Choreography specifically refers to using events to coordinate a multi-step business process across several services, where the completion of one step is what triggers the next. Simple pub/sub notifications (like “send an analytics event whenever anyone clicks a button”) are event-driven, but they aren’t really choreographing a business transaction unless later steps depend on earlier ones completing successfully.

4.1 How to read this diagram

On the left, the Orchestrator is like the director in the play analogy — it knows the entire recipe and calls each service directly, waiting for a response before calling the next. On the right, there is no single box that “knows everything.” The Order Service simply shouts “OrderPlaced!” into the Event Bus and moves on. The Payment Service happens to be listening for that shout, reacts, and then shouts its own event. This chain continues — like a row of dominoes, each one falling because the previous one fell, not because someone pushed each domino individually.

4.2 Side-by-side comparison

5.1 The main building blocks

• Producer service — publishes events when something happens inside it (for example, the Order Service publishing OrderPlaced).
• Consumer service — subscribes to one or more event types and reacts (for example, the Payment Service consuming OrderPlaced).
• Event broker / message bus — the “postal system” (Kafka, RabbitMQ, and so on) that reliably delivers events.
• Event schema / contract — an agreed-upon structure for each event (fields, types), so producers and consumers understand each other. Often defined with tools like Avro, Protobuf, or JSON Schema.
• Dead-letter queue (DLQ) — a special holding area for events that failed processing repeatedly, so they don’t get lost or block the main flow.
• Schema registry — a central catalog that stores and validates event schema versions, preventing producers and consumers from silently breaking each other.

{
  "eventType": "OrderPlaced",
  "eventId": "b23f-...-91a2",
  "occurredAt": "2026-07-16T10:15:00Z",
  "orderId": "ORD-88213",
  "customerId": "CUST-4471",
  "items": [
    { "sku": "PIZZA-001", "qty": 2 }
  ],
  "totalAmount": 24.50
}

6.1 Step-by-step explanation

1. Save locally

   The Order Service finishes creating an order in its own database.

2. Publish the event durably

   It publishes an OrderPlaced event to the broker. The broker durably stores this event (writes it to disk, often replicated across machines) before confirming — critical, otherwise events could be lost if the broker crashes.

3. Deliver to subscribers

   The broker then pushes (or the consumer pulls) this event to every subscriber of the orders topic — here, the Payment Service.

4. Process independently

   The Payment Service processes the event: it charges the card using its own internal logic, entirely unaware of what Inventory or Notifications will do.

5. Publish the next fact

   Once done, Payment Service publishes its own event, PaymentCompleted.

6. Chain continues

   The Inventory Service, subscribed to payment events, receives it and reserves stock — again, without knowing who’s listening downstream.

6.2 Java example: a simple event producer

Below is a simplified, illustrative example (not tied to one specific broker’s exact API) showing how a Java service might publish an event after saving an order.

public class OrderService {

    private final EventPublisher eventPublisher;
    private final OrderRepository orderRepository;

    public OrderService(EventPublisher eventPublisher, OrderRepository orderRepository) {
        this.eventPublisher = eventPublisher;
        this.orderRepository = orderRepository;
    }

    public void placeOrder(OrderRequest request) {
        // 1. Save order locally — this is our own service's transaction
        Order order = orderRepository.save(new Order(request));

        // 2. Build the event payload — the "fact" we are announcing
        OrderPlacedEvent event = new OrderPlacedEvent(
            order.getId(), order.getCustomerId(), order.getItems(), order.getTotal()
        );

        // 3. Publish to the broker — we do NOT call PaymentService directly
        eventPublisher.publish("orders.OrderPlaced", event);
    }
}

6.3 Java example: a simple event consumer

public class PaymentEventListener {

    private final PaymentGateway paymentGateway;
    private final EventPublisher eventPublisher;
    private final ProcessedEventStore processedEventStore; // for idempotency

    @EventListener(topic = "orders.OrderPlaced")
    public void onOrderPlaced(OrderPlacedEvent event) {

        // Guard against duplicate delivery (idempotency check)
        if (processedEventStore.alreadyHandled(event.getEventId())) {
            return; // already processed, do nothing
        }

        boolean success = paymentGateway.charge(event.getCustomerId(), event.getTotal());

        if (success) {
            eventPublisher.publish("payments.PaymentCompleted",
                new PaymentCompletedEvent(event.getOrderId()));
        } else {
            eventPublisher.publish("payments.PaymentFailed",
                new PaymentFailedEvent(event.getOrderId(), "card_declined"));
        }

        processedEventStore.markHandled(event.getEventId());
    }
}

Notice two important defensive habits in the consumer code: checking whether the event was already handled (idempotency), and publishing a failure event rather than silently swallowing errors. Both are essential in real choreography systems, because network hiccups and broker retries can deliver the same event more than once.

This uses the Choreography-based Saga pattern, one of the most asked-about patterns in system design interviews.

7.1 Why compensation instead of “rollback”?

In a single database, if something fails, you just run ROLLBACK and everything reverts instantly. But here, the Payment Service already charged the customer’s card in a separate system — you cannot “un-charge” it with a database command. Instead, you must explicitly issue a refund — a compensating action that undoes the business effect, not a magic technical undo.

7.2 Lifecycle stages of an event

1. Creation

   A service decides a fact is worth announcing.

2. Serialization

   The event object is converted into bytes (JSON, Avro, Protobuf) for transport.

3. Publish

   Sent to the broker, which durably persists it.

4. Storage/Retention

   The broker keeps the event for a configured period (Kafka, for example, can retain events for days or indefinitely).

5. Delivery

   Pushed or pulled to each subscribed consumer.

6. Processing

   The consumer executes its own local logic.

7. Acknowledgement

   The consumer tells the broker “I’ve handled this,” so it isn’t redelivered unnecessarily.

8. Dead-lettering (if needed)

   If processing keeps failing, the event is moved to a DLQ for manual or automated investigation.

8.1 Choreography-based Saga

Already explained above — a chain of events and compensations with no central coordinator.

8.2 Event Sourcing

Storing state as an ordered log of events rather than as a single row of “current values.” Very natural fit for choreography since the system already thinks in events.

8.3 CQRS (Command Query Responsibility Segregation)

What it is. Splitting the model used to write data (commands) from the model used to read data (queries), often paired with event sourcing and choreography — write-side services emit events, and separate read-side services build fast, denormalised “views” by consuming those events.

8.4 Event-Carried State Transfer

What it is. Events that carry enough data so the receiving service doesn’t need to call back to ask for more details.

8.5 Competing Consumers

What it is. Multiple instances of the same service subscribe to the same topic/queue, but each event is only processed by one of them — spreading load across instances.

8.6 Outbox Pattern

What it is. A technique to guarantee that a database write and an event publish happen together reliably. The service writes the event into an “outbox” table in the same local database transaction as its business data, and a separate background process reads that table and publishes the events to the broker.

Why it exists. Without it, you risk saving data but crashing before publishing the event (or vice versa) — a classic “dual write” problem.

public void placeOrder(OrderRequest request) {
    // Both writes happen in ONE local database transaction
    orderRepository.save(order);
    outboxRepository.save(new OutboxMessage("OrderPlaced", order.toEventPayload()));
    // A separate poller reads outbox rows and publishes them to Kafka reliably
}

Choreography systems typically scale extremely well, because each service can add more instances independently, and the event broker (like Kafka) is specifically engineered to handle very high throughput.

11.1 Partitioning

What it is. Splitting a topic into multiple independent partitions so multiple consumer instances can process events in parallel, while events with the same key (for example, same order ID) still go to the same partition to preserve order for that key.

11.2 Throughput vs Latency

Throughput is how many events per second the system can process. Latency is how long it takes one single event to be fully processed end-to-end. Choreography systems often optimise heavily for throughput (batching events, asynchronous processing), which can slightly increase per-event latency compared to a direct synchronous call — a classic trade-off.

11.3 Backpressure

What it is. A mechanism to slow down producers (or buffer events) when consumers can’t keep up, preventing the system from being overwhelmed.

11.4 Batching and Compression

Real brokers like Kafka batch many small events together and compress them before sending over the network — dramatically improving throughput at the cost of a few milliseconds of added latency per batch.

12.1 Replication

What it is. Keeping multiple copies of the same event data across different machines (brokers), so if one machine dies, another copy is still available.

12.2 At-least-once vs Exactly-once vs At-most-once delivery

12.3 Retry with backoff

When a consumer fails to process an event (say, a downstream payment API is briefly down), it shouldn’t retry instantly and repeatedly. Instead, it waits progressively longer between attempts — this is called exponential backoff — to avoid hammering an already struggling downstream system.

12.4 Circuit Breaker

What it is. A safety mechanism that “trips” and stops calling a failing dependency for a while, instead of retrying endlessly and making things worse.

12.5 Disaster Recovery

Production choreography systems typically replicate their event broker across multiple data centres or cloud regions, and maintain event retention long enough that consumers can “replay” missed events after an outage, catching up to the current state.

13.1 CAP Theorem

What it is. A rule stating that in a distributed system, when a network partition (a communication breakdown between machines) happens, you must choose between Consistency (every reader sees the same, latest data) and Availability (every request gets a response, even if it might be slightly outdated).

Most choreography-based systems lean toward Availability + Eventual Consistency (AP) — services keep working locally and reconcile once events catch up, rather than freezing until every service agrees.

13.2 Consensus

What it is. A way for multiple machines to agree on one single value or decision, even if some machines fail or messages are delayed. Algorithms like Raft and Paxos solve this — and they’re what keeps a Kafka broker cluster (via a controller/coordination layer) agreeing on which broker is the leader for each partition.

13.3 Partitioning & Sharding

Already touched on above — splitting data or event streams by a key so work can be parallelised across machines, while keeping related events (same key) in order.

13.4 Failure Recovery & Replay

Because brokers like Kafka retain events for a configurable time, a consumer that crashes for an hour can simply “replay” from where it left off (its last committed offset) once it’s back up — catching up automatically without any events being lost. This “replayability” is one of choreography’s biggest reliability superpowers compared to older messaging systems that deleted messages the instant they were read.

13.5 Concurrency Considerations

When multiple instances of the same consumer service process events in parallel, you must guard against race conditions — for example, two instances trying to reserve the last item of stock at the same time. Techniques include optimistic locking (checking a version number before saving) and using a partition key (e.g., product ID) so all events about the same product always land on the same consumer instance, avoiding parallel conflicts entirely.

• Authentication between services and the broker — using mutual TLS (mTLS) or SASL credentials so only trusted services can publish or subscribe to topics.
• Authorization / ACLs — restricting which services are allowed to publish to or consume from specific topics (for example, only Payment Service can publish to the payments topic).
• Encryption in transit — TLS between services and broker, and between broker nodes.
• Encryption at rest — encrypting event data stored on broker disks, important since brokers often retain events for days.
• Sensitive data minimisation — avoid putting things like full credit card numbers or passwords inside events; use tokens/references instead, since events may be replayed, logged, or retained much longer than a typical API call.
• Schema validation as a security boundary — rejecting malformed or unexpected event payloads at the edge prevents injection-style attacks from propagating deep into your system.
• Audit trails — since events are naturally an append-only log of “what happened,” they double as a strong audit trail for compliance (useful in finance, healthcare).

Because the “flow” in choreography is scattered across many services, observability tooling becomes absolutely essential — arguably more important here than in orchestration.

15.1 Distributed Tracing

What it is. Attaching a shared “trace ID” (sometimes called a correlation ID) to an event when it’s first created, and passing that same ID along through every event in the chain, so you can later reconstruct the entire journey of one business transaction across all the services it touched.

15.2 Key metrics to monitor

• Consumer lag — how far behind a consumer is from the latest event published (a growing lag means trouble).
• Event throughput — events published/consumed per second, per topic.
• Processing latency — time between an event being published and being fully processed.
• Dead-letter queue size — a growing DLQ signals a systemic processing problem.
• Error/retry rate — spikes often indicate a downstream dependency issue.

15.3 Logging best practices

Always log the event type, event ID, and trace ID together with any error — this is the minimum needed to later reconstruct “what went wrong, and where in the chain.”

In modern cloud environments, choreography is typically deployed using:

• Containers (Docker) + Kubernetes — each service (and often the broker itself) runs in containers, orchestrated (in the deployment sense, not the messaging sense!) by Kubernetes for scaling and self-healing.
• Managed event brokers — AWS EventBridge/MSK (managed Kafka), Google Cloud Pub/Sub, Azure Service Bus/Event Hubs — so teams don’t have to operate the broker cluster themselves.
• Serverless consumers — AWS Lambda or Google Cloud Functions can be triggered directly by events, scaling automatically to zero when idle and up instantly when volume spikes.
• CI/CD pipelines — each service is deployed independently, often multiple times a day, since choreography’s loose coupling means one team’s deployment rarely requires coordinating with every other team.
• Blue-green / canary deployments — safely rolling out a new version of a consumer by initially routing only a small percentage of events to it, watching for errors before shifting all traffic.

16.1 Cost Optimisation

Running a message broker and many independently deployed services isn’t free, so production teams actively manage cost in a few common ways:

• Right-sizing partitions and retention — keeping only as much event history as you actually need for replay and audit purposes; excessive retention on a high-throughput topic can quietly become one of the largest storage costs in a system.
• Autoscaling consumers based on lag — instead of running a fixed, always-on fleet sized for peak traffic, consumer instance counts scale up when consumer lag grows and scale back down when the queue is caught up.
• Compression — compressing event batches (e.g., using Snappy or LZ4 with Kafka) meaningfully reduces both network and storage costs at high volume.
• Choosing managed brokers wisely — for smaller workloads, a managed serverless broker (pay-per-event) is often cheaper than operating a self-managed cluster sized for constant availability; at very high, sustained volume, the economics can flip in the other direction.

17.1 Database-per-service

In choreography-based microservices, each service typically owns its own private database — no other service is allowed to read or write to it directly. This is essential: if two services shared a database, they’d become tightly coupled again, defeating the whole purpose of choreography.

17.2 Caching read models

Following the CQRS pattern mentioned earlier, a service can build a fast, cached “read view” by consuming events from other services — for example, a Product Catalog Service might cache “current stock levels” locally by listening to StockReserved and StockReplenished events, avoiding a live call to the Inventory Service for every page view.

17.3 Load balancing consumers

As described in the “competing consumers” pattern, multiple instances of the same consumer service are typically placed behind the broker’s own partition-assignment mechanism (not a traditional HTTP load balancer) — the broker itself decides which instance gets which partition’s events, rebalancing automatically if an instance crashes or scales up.

Choreography doesn’t mean services never use regular request/response APIs at all — most real systems use a healthy mix:

• Synchronous APIs (REST/gRPC) — used for immediate, user-facing queries where the caller genuinely needs a fast answer right now (for example, “show me this product’s price”).
• Asynchronous events (choreography) — used for background business processes that don’t need an instant answer, and that benefit from loose coupling (for example, “process this order’s payment eventually, reliably”).

This mixed style is sometimes called a hybrid architecture, and it is extremely common in real production systems — pure, 100% choreography is rare; pure orchestration is also rare. Most large systems use orchestration for a few well-defined, critical workflows (like refund approval) and choreography for the broader, high-volume, loosely coupled event flows.

19.1 Best Practices

1. Version every event schema from day one

   Use names like OrderPlacedV1, OrderPlacedV2 so changes never silently break consumers.

2. Always design consumers to be idempotent

   Assume duplicate delivery will happen — because on any real broker, sooner or later, it will.

3. Attach a trace/correlation ID to every event

   This is the observability foundation on which everything else stands or falls.

4. Keep events as immutable facts stated in the past tense

   OrderPlaced, not PlaceOrder. Names matter more than most engineers appreciate.

5. Document which services publish and consume which events

   A simple “event catalog” saves enormous confusion later.

6. Use the Outbox pattern

   To avoid the dual-write problem between your database and your broker.

7. Set up a dead-letter queue and actively monitor it

   Don’t let poison messages silently vanish or endlessly retry.

8. Keep event payloads reasonably self-contained

   Event-carried state transfer reduces chatty follow-up calls.

9. Invest early in contract testing between producers and consumers

   So a schema change is caught in a build pipeline rather than discovered in production weeks later.

10. Build an event catalog dashboard or wiki page

    List every event type, its owning team, its schema, and who consumes it — this single artifact often saves more debugging time than any other practice on this list.

11. Treat compensating actions as first-class features

    Give them their own tests and design reviews, not an afterthought bolted on after the “happy path” is done.

19.2 Common Mistakes

Service choreography is a distributed cooperation style: many independent services complete one business process together, coordinating not through commands from a boss but through events they publish and consume. The result is loose coupling and near-linear scaling, at the cost of harder end-to-end visibility.

1. Service choreography is a way for independent services to cooperate on a shared business process by reacting to events, without a central controller directing every step.
2. It contrasts with orchestration, where one component explicitly calls each service in sequence.
3. Core building blocks: services, events, an event broker/bus, publish/subscribe messaging, and agreed-upon event schemas.
4. The Saga pattern (with compensating actions) is the standard way to handle multi-step transactions and failures in a choreographed system.
5. Idempotency, schema versioning, distributed tracing, and dead-letter queues are not optional extras — they are essential production requirements.
6. Real companies (Netflix, Amazon, Uber, and many banks) use choreography extensively, usually blended with orchestration for specific critical workflows.
7. Choreography trades easy visibility of the “whole picture” for looser coupling, independent scalability, and resilience against any single point of control failing.
8. Events are past-tense facts, not commands — and this naming discipline is what keeps services autonomous.
9. Topics broadcast; queues distribute. Choreography almost always wants topics.
10. The single biggest reason choreography systems fail in production is missing observability, not missing features.

“Events aren’t messages that ask for something — they are announcements of what has already become true.”