In the Choreography model, services coordinate a business process by publishing and reacting to events, with no central controller directing the workflow.
Key Points: • Each service performs its own step and then publishes an event describing what happened, without knowing or caring which services will react to it. • Other services independently subscribe to the events they care about and trigger their own logic in response, creating a chain reaction across the system. • This keeps services loosely coupled, since none of them needs direct knowledge of the others — they only need to agree on event contracts. • As more services get added, tracing the overall flow purely from events can become harder, which is the main trade-off compared to orchestration. • A message broker like Kafka typically carries these events, and consumers process them asynchronously and independently of each other.
Example: In an e-commerce checkout, the Order Service publishes an "Order Created" event; the Payment Service listens and processes payment, publishing "Payment Processed" once done; the Shipping Service listens for that event and begins shipping — each service reacting only to the event it cares about.
Interview Tip: A concise interview answer is:
"A good example is checkout in an e-commerce app: Order Service publishes 'Order Created', Payment Service reacts and publishes 'Payment Processed', and Shipping Service reacts to that in turn. Each service only knows about the events it consumes and produces, not about the other services directly, which is what makes choreography loosely coupled."