Event-driven architecture with choreography coordinates microservices through events rather than a central controller, giving flexibility and independence at the cost of harder traceability.
Key Points: • Pros: services operate independently and react to events as they occur, which improves scalability and reduces direct coupling between services. • Pros: adding a new service that reacts to an existing event requires no change to the services that publish it, making the system easier to extend. • Cons: because control flow is decentralized, it can be hard to see or debug the overall business process just by looking at any single service. • Cons: ensuring data consistency is harder since updates propagate asynchronously, which can create temporary data discrepancies across services. • Cons: without careful event versioning and tracing, it's easy to end up with implicit, hard-to-track dependencies between services through shared events.
Example: In an order flow with choreography, the Order service publishes an OrderPlaced event, and Payment, Inventory, and Notification services each independently subscribe and react, which makes adding a new Loyalty Points service simple, but makes it harder to answer "what exactly happens when an order is placed" without tracing across all four services.
Interview Tip: A concise interview answer is:
"Choreography's big win is loose coupling and easy extensibility, since services just react to events without a central controller needing to know about them. The trade-off is that the overall business process becomes harder to see and debug, and keeping data consistent across services requires careful handling of asynchronous, eventually-consistent updates."