Choreography vs orchestration in Microservices - Design Approaches Compared

Design: Microservices Communication Coordination

Design focuses on comparing choreography and orchestration approaches for coordinating microservices workflows. Does not cover detailed implementation of each microservice business logic.

Functional Requirements

FR1: Coordinate multiple microservices to complete business workflows

FR2: Ensure services communicate reliably and in correct order

FR3: Support asynchronous and synchronous interactions

FR4: Handle failures gracefully and allow retries

FR5: Allow easy addition or removal of services without major rewrites

Non-Functional Requirements

NFR1: Support up to 1000 concurrent workflow executions

NFR2: API response latency p99 under 300ms for synchronous calls

NFR3: System availability 99.9% uptime

NFR4: Minimal coupling between services to allow independent deployment

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Service Mesh for routing

Message Broker (e.g., Kafka, RabbitMQ) for event-driven communication

Workflow Orchestrator (e.g., Temporal, Camunda) for orchestration

Microservices emitting and consuming events

Monitoring and logging tools

Design Patterns

Event-driven choreography pattern

Centralized orchestration pattern

Saga pattern for distributed transactions

Publish-subscribe messaging

Circuit breaker for failure handling

Reference Architecture

          +---------------------+          
          |  Client / Frontend  |          
          +----------+----------+          
                     |                     
          +----------v----------+          
          |     API Gateway     |          
          +----------+----------+          
                     |                     
        +------------+------------+        
        |                         |        
+-------v-------+         +-------v-------+
| Orchestrator  |         | Message Broker|
| (Centralized) |         | (Event Bus)   |
+-------+-------+         +-------+-------+
        |                         |        
+-------v-------+         +-------v-------+
| Microservice1 |         | Microservice1 |
+---------------+         +---------------+
        |                         |        
+-------v-------+         +-------v-------+
| Microservice2 |         | Microservice2 |
+---------------+         +---------------+
        |                         |        
       ...                       ...       

Components

API Gateway

Nginx, Kong, or AWS API Gateway

Entry point for client requests, routes to services or orchestrator

Orchestrator

Temporal, Camunda, or AWS Step Functions

Central component controlling workflow steps and service calls

Message Broker

Kafka, RabbitMQ, or AWS SNS/SQS

Event bus enabling services to publish and subscribe to events

Microservices

Any language/framework (e.g., Spring Boot, Node.js)

Business logic units that perform tasks and communicate via events or orchestrator

Monitoring & Logging

Prometheus, Grafana, ELK Stack

Track system health, workflow progress, and failures

Request Flow

1. Client sends request to API Gateway.

2. In orchestration: API Gateway forwards request to Orchestrator.

3. Orchestrator calls Microservice1 synchronously or asynchronously.

4. Microservice1 completes task and returns result to Orchestrator.

5. Orchestrator calls next microservice(s) based on workflow logic.

6. Orchestrator returns final response to API Gateway, then to client.

7. In choreography: Microservice1 performs task and publishes event to Message Broker.

8. Microservice2 subscribes to event, performs its task, then publishes next event.

9. This event-driven chain continues until workflow completes.

10. Client may receive asynchronous notification or poll for status.

Database Schema

Entities: - WorkflowInstance: id, status, start_time, end_time - ServiceTask: id, workflow_instance_id (FK), service_name, status, input_data, output_data, start_time, end_time - Event: id, event_type, payload, timestamp Relationships: - One WorkflowInstance has many ServiceTasks - Events are linked to ServiceTasks by context or correlation id This schema supports tracking workflow progress and event history.

Scaling Discussion

Bottlenecks

Orchestrator becomes a single point of failure and bottleneck at high concurrency

Message Broker overload due to high event volume

Microservices overwhelmed by burst traffic

API Gateway limits throughput

Database contention for workflow state updates

Solutions

Scale Orchestrator horizontally or use distributed orchestrators

Partition Message Broker topics and use multiple brokers

Implement autoscaling for microservices based on load

Use API Gateway clustering and caching

Use optimized database indexing, sharding, or NoSQL for state storage

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing and explaining both choreography and orchestration approaches, 10 minutes discussing scaling and trade-offs, 5 minutes for questions.

Explain difference between choreography (decentralized) and orchestration (centralized)

Discuss pros and cons of each approach in terms of control, complexity, and scalability

Describe components needed for each approach

Show understanding of failure handling and monitoring

Highlight how to scale and maintain system reliability

Practice

1. Which statement best describes choreography in microservices architecture?

easy

A. A central controller manages all service interactions and workflow.

B. Services communicate directly through events without a central controller.

C. Services are tightly coupled and depend on a single database.

D. All services share the same codebase for coordination.

Solution

1. Step 1: Understand choreography communication style

   Choreography means services send and receive events directly without a central manager.

2. Step 2: Compare with orchestration

   Orchestration uses a central controller, unlike choreography which is decentralized.

3. Final Answer:

   Services communicate directly through events without a central controller. -> Option B

4. Quick Check:

   Choreography = direct event communication [OK]

Hint: Choreography means no central boss, services talk directly [OK]

Common Mistakes:

• Confusing choreography with orchestration
• Thinking choreography requires a central controller
• Assuming choreography means tight coupling

2. Which of the following is the correct syntax to describe orchestration in microservices?

easy

A. A central orchestrator calls each service in sequence.

B. Services share a global state without coordination.

C. Services emit events and listen to each other directly.

D. Services communicate only through a shared database.

Solution

1. Step 1: Identify orchestration pattern

   Orchestration uses a central controller that manages service calls in order.

2. Step 2: Eliminate incorrect options

   Options A, B, and D describe other patterns or incorrect behaviors.

3. Final Answer:

   A central orchestrator calls each service in sequence. -> Option A

4. Quick Check:

   Orchestration = central controller calls [OK]

Hint: Orchestration means one boss controls the workflow [OK]

Common Mistakes:

• Mixing event-driven with orchestrated calls
• Assuming orchestration means no central control
• Confusing shared database with orchestration

3. Consider this scenario: Service A emits an event, Service B listens and processes it, then emits another event for Service C. Which pattern is this an example of?

medium

A. Choreography with event-driven communication

B. Orchestration with central controller

C. Monolithic service call chain

D. Shared database coordination

Solution

1. Step 1: Analyze event flow

   Service A emits event, B listens and emits another event, C listens next. This is event-driven chain.

2. Step 2: Match pattern to description

   This direct event passing without central control matches choreography.

3. Final Answer:

   Choreography with event-driven communication -> Option A

4. Quick Check:

   Event chain without central control = Choreography [OK]

Hint: Event chain without boss = choreography [OK]

Common Mistakes:

• Assuming event flow means orchestration
• Confusing monolith with microservices
• Thinking shared database is event-driven

4. A developer implemented orchestration but forgot to handle failures in the central controller. What is the likely problem?

medium

A. Services will communicate directly causing chaos.

B. There will be no impact since orchestration is event-driven.

C. Services will ignore the central controller and run independently.

D. The workflow may stop or behave unpredictably on errors.

Solution

1. Step 1: Understand orchestration failure impact

   Central controller manages workflow; missing error handling causes stops or bad states.

2. Step 2: Eliminate wrong options

   Options A and C describe choreography or independent services, not orchestration failure. There will be no impact since orchestration is event-driven. is false because orchestration is not event-driven.

3. Final Answer:

   The workflow may stop or behave unpredictably on errors. -> Option D

4. Quick Check:

   Orchestration needs error handling to avoid workflow breaks [OK]

Hint: No error handling in orchestrator breaks workflow [OK]

Common Mistakes:

• Confusing orchestration failure with choreography behavior
• Ignoring error handling importance
• Assuming orchestration is event-driven

5. You need to design a microservices system that must scale easily and avoid a single point of failure. Which approach is better and why?

hard

A. Use a monolithic architecture to simplify deployment.

B. Use orchestration for centralized control and easier debugging.

C. Use choreography for loose coupling and better scalability.

D. Use shared database coordination for consistency.

Solution

1. Step 1: Identify scalability and failure requirements

   System must scale easily and avoid single failure point, so loose coupling is key.

2. Step 2: Match pattern to requirements

   Choreography allows services to work independently, improving scalability and fault tolerance.

3. Step 3: Eliminate other options

   Orchestration centralizes control, risking single failure point. Monolith and shared DB reduce scalability.

4. Final Answer:

   Use choreography for loose coupling and better scalability. -> Option C

5. Quick Check:

   Loose coupling + scalability = choreography [OK]

Hint: Loose coupling means choreography for scale and fault tolerance [OK]

Common Mistakes:

• Choosing orchestration despite single failure risk
• Confusing monolith with microservices
• Ignoring scalability in design choice