apidays Australia 2025 | Orchestrator vs. Choreography

As microservices continue to underpin modern API-driven architectures, the choice between orchestration and choreography has proven critical for scalability, resilience, and long-term maintainability. In this talk, Patrick Zhao, Domain Architect at 7-Eleven Australia, examined the strengths and trade-offs of each approach using real-world retail scenarios.

The session unpacked when centralized orchestration is best suited for structured, process-driven workflows, and when event-driven choreography enables highly scalable, loosely coupled systems. Attendees gained a clear, practical decision-making framework and actionable best practices for designing APIs and microservices that balance control with autonomy.

------------------------------------

Conference Details:
Conference: apidays Australia 2025
Theme: Platforms, Products, and People: The Power of APIs in the Age of AI
Date: 29 - 30 October 2025 • MCEC, Melbourne Australia

--------------------------

Resources from apidays:
Join our upcoming conferences: https://www.apidays.global/
Read the latest API news: https://www.apiscene.io
Explore the API Landscape: https://apilandscape.apiscene.io/

Transcript

1. Orchestrator vs. Choreography Building Scalable Retail APIs through Smarter Microservice Design Finding the right balance between control and autonomy in a distributed retail platform. Patrick Zhao | Domain Architect | 7-Eleven Australia
2. From Simple to Chaos
3. From Simple to Chaos
4. 1000 services will create how many p2p bidirectional connections? 2 arrows per pair ó total arrows = 2 × n(n 2 1)/2 = n(n 2 1) 1000 * (1000 - 1) = 999,000
5. From Simple to Chaos Image credits: Pixabay
6. Who Decides and Who Coordinates? Who decides what happens next? Who coordinates how it happens?
7. Orchestration vs. Choreography Orchestration: The Conductor Choreography: The Dancers
8. Orchestration vs. Choreography Orchestration Orchestra tor Service A Independent downstream service Service B Independent downstream service Client Request Initiates process to orchestrator Centralized control Defined execution sequences High visibility for workflow Choreography Message Broker Client Request Initiates events to the central broker Service A Publishes and subscribes via broker Service B Publishes and subscribes via broker Decentralized interaction Event-driven communication Loose coupling between services
9. Nuance in "Message Broker" , "Event Bus" and "Message Queue" Message Broker: A middleware that enables complex communication between different applications and services. Message Queue (Point-to-Point): Messages are delivered to a specific consumer (or consumer group). Once consumed, it9s gone. Event Bus/Stream (Pub/Sub): Events are broadcast to many subscribers. They can be replayed, stored, and multiple consumers can react independently.
10. Example Scenario: Order Fulfillment Let's examine how orchestration and choreography handle a typical retail order fulfillment process involving payment, inventory, shipping, and notification services. Order Placement Customer completes checkout; order received. Payment Processing Payment service validates transaction. Inventory Management Inventory service reserves stock. Shipping Coordination Logistics schedules pickup and labels. Customer Communication Notification service sends updates.
11. Orchestration in Action Order Orchestrator Workflow The Order Orchestrator calls services in a strict sequence: Payment Inventory Shipping Notification It manages state, handles failures, and triggers compensation if needed. Advantages: Clear visibility and logging Simplified transaction control Easier compliance & audit ¦ Trade-off: Single point of coordination 4 may become a bottleneck.
12. Choreography in Action Event-Driven Flow OrderService publishes OrderPlaced PaymentService subscribes, processes, then publishes PaymentCompleted InventoryService reacts, publishes StockReserved ShippingService picks up the chain, and so on. Advantages: Loosely coupled, naturally scalable Easier to evolve individual services Fits modern event-stream platforms (Kafka, Event Grid, SNS) ¦ Trade-off: Harder to track end-to-end flow and handle failures consistently.
13. Hybrid Approach: Best of Both Worlds Strategic Combination Use orchestration for critical, transactional paths ³ Payment, inventory, order validation Use choreography for peripheral, reactive paths ³ Notifications, analytics, loyalty updates Design Principle: Centralize where you must, decentralize where you can.
14. Implementation Guideline for Retail 01 Assess Current State Map existing service dependencies and message flows. 02 Define Clear Boundaries Apply DDD principles to isolate domains (Order, Payment, Inventory, etc.). 03 Select Pattern by Context Critical process ³ Orchestration Reactive or scalable process ³ Choreography 04 Implement Observability Early Distributed tracing (OpenTelemetry), structured logging, correlation IDs.
15. Key Takeaways No One-Size-Fits-All 4 choose based on business and technical context. ¶ Think Hybrid 4 orchestrate critical workflows, choreograph the rest. Observability Is Critical 4 visibility equals confidence. Prepared for Failure 4 circuit breakers, retries. Version Everything & Test Contracts 4 avoid breaking changes between services.
16. Appendix - When to Choose Which Pattern Criteria Orchestration Choreography Hybrid Workflow Complexity Sequential, rule-based Simple, event-driven Mix of both Consistency Strong / ACID Eventual Context-based Error Handling Centralized Distributed Mixed Team Skills Imperative mindset Reactive mindset Both Audit & Compliance Easy audit trail Harder, needs tracing Depends Scalability Bottleneck possible Highly scalable Balanced Coupling Tighter to orchestrator Very loose Moderate Speed of Development Faster for known flows Slower to start, faster later Balanced Control vs. Flexibility More control More autonomy Balance
17. Thank You Questions? Let9s discuss how orchestration and choreography can power scalable retail APIs. Patrick | Domain Architect | 7-Eleven Australia