The Choreography pattern promotes loose coupling between microservices by having each service react to events independently, without any service needing direct knowledge of another service's implementation or the overall workflow.
Key Points: • Services communicate by publishing and subscribing to events rather than calling each other directly, so no service holds a hardcoded dependency on another's API. • A publishing service doesn't need to know which services, if any, are listening for its events, which keeps it decoupled from downstream consumers. • New services can be added to react to existing events without requiring any change to the services that originally publish them. • Because there's no shared central coordinator, no single service accumulates knowledge of the full workflow, which limits how tightly any one service is coupled to the process as a whole. • The trade-off for this loose coupling is reduced end-to-end visibility, since the overall process logic is implicit in how services react to each other's events.
Example: Adding a new Fraud Detection service that reacts to OrderPlaced events requires no changes to the Order service that publishes them, since Fraud Detection just subscribes to an existing event stream rather than the Order service needing to call it directly.
Interview Tip: A concise interview answer is:
"Choreography keeps services loosely coupled because they interact only through events, not direct calls, so a publisher doesn't need to know who's listening and new subscribers can be added without touching existing services. That flexibility comes at the cost of a workflow that's implicit across many services rather than visible in one place."