Event choreography vs orchestration in Kafka - Visual Side-by-Side Comparison

Process Flow - Event choreography vs orchestration

Start Event

↓

Event Choreography

↓

Multiple Services Listen & React

↓

Each Service Emits Events

↓

Other Services React

↓

No Central Controller

↓

Start Event

↓

Event Orchestration

↓

Central Orchestrator Service

↓

Orchestrator Sends Commands

↓

Services Perform Tasks

↓

Orchestrator Tracks Progress

↓

Process Ends

Event choreography lets services react to events independently without a central controller, while orchestration uses a central controller to direct service actions.

Execution Sample

Kafka

1. Service A emits 'OrderCreated' event
2. Service B listens and emits 'PaymentProcessed'
3. Service C listens and emits 'OrderShipped'

// Orchestration example
1. Orchestrator sends 'ProcessPayment' to Service B
2. Service B replies 'PaymentDone'
3. Orchestrator sends 'ShipOrder' to Service C

Shows event flow in choreography where services emit and listen to events, and orchestration where a central orchestrator commands services.

Process Table

Step	Event/Command	Service Action	Emitted Event	Next Listener/Action
1	'OrderCreated' emitted	Service A emits event	'OrderCreated'	Service B listens
2	'OrderCreated' received	Service B processes payment	'PaymentProcessed' emitted	Service C listens
3	'PaymentProcessed' received	Service C prepares shipment	'OrderShipped' emitted	No further listeners
4	Process ends	No central controller, flow ends naturally	No event	No action
5	'ProcessPayment'	Orchestrator sends command to Service B	No event	Service B processes payment
6	'PaymentDone' reply	Service B replies to orchestrator	No event	Orchestrator sends 'ShipOrder' to Service C
7	'ShipOrder' command	Service C ships order	No event	Orchestrator waits for completion
8	Process ends	Orchestrator confirms completion	No event	Process complete

💡 Choreography ends when no more events are emitted; orchestration ends when orchestrator confirms all tasks done.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 5	After Step 6	After Step 7	Final
Events in Kafka	[]	['OrderCreated']	['OrderCreated', 'PaymentProcessed']	['OrderCreated', 'PaymentProcessed', 'OrderShipped']	['OrderCreated', 'PaymentProcessed', 'OrderShipped']	['OrderCreated', 'PaymentProcessed', 'OrderShipped']	['OrderCreated', 'PaymentProcessed', 'OrderShipped']	['OrderCreated', 'PaymentProcessed', 'OrderShipped']
Orchestrator Commands	[]	[]	[]	[]	['ProcessPayment']	['ProcessPayment', 'PaymentDone']	['ProcessPayment', 'PaymentDone', 'ShipOrder']	['ProcessPayment', 'PaymentDone', 'ShipOrder', 'Completed']
Service States	Idle	Service A emitted event	Service B processed payment	Service C shipped order	Idle	Service B processed payment	Service C shipped order	All tasks done

Key Moments - 3 Insights

Why does event choreography not have a central controller?

Because each service listens and reacts independently by emitting events, as shown in execution_table rows 1-4, no single service controls the flow.

How does the orchestrator know when to send the next command?

The orchestrator waits for replies from services before sending the next command, as seen in execution_table rows 5-7 where commands and replies coordinate the flow.

Can events in choreography cause infinite loops?

Yes, if services keep emitting events in response to each other without stopping, but usually design prevents this; the execution_table shows a natural end at step 4.

Visual Quiz - 3 Questions

Look at the execution_table, what event does Service B emit after receiving 'OrderCreated'?

A 'OrderShipped'

B 'PaymentProcessed'

C 'ProcessPayment'

D 'PaymentDone'

💡 Hint

Check execution_table row 2 under 'Emitted Event'

At which step does the orchestrator send the 'ShipOrder' command?

A Step 7

B Step 5

C Step 6

D Step 8

💡 Hint

Look at execution_table row 7 under 'Event/Command'

If Service C never emits 'OrderShipped' in choreography, what happens?

A The process ends normally

B Service B emits 'OrderShipped' instead

C The event flow may stall or wait indefinitely

D Orchestrator takes over automatically

💡 Hint

Refer to execution_table rows 3 and 4 about event flow ending

Concept Snapshot

Event Choreography:
- Services emit and listen to events independently
- No central controller
- Flow driven by events

Event Orchestration:
- Central orchestrator sends commands
- Orchestrator tracks progress
- Flow controlled centrally

Full Transcript

Event choreography means services talk by sending events to each other without a boss. Each service listens for events and reacts by doing work and sending new events. This creates a chain of reactions. Event orchestration means one central service controls the process. It sends commands to other services and waits for replies before sending the next command. In Kafka, events are messages on topics. In choreography, services produce and consume events freely. In orchestration, the orchestrator sends commands and listens for responses. The execution table shows how events flow step-by-step in both styles. Variables track events in Kafka, commands from orchestrator, and service states. Key moments explain why choreography has no controller and how orchestrator manages flow. The quiz checks understanding of event emissions and command steps. Remember, choreography is like a dance where everyone follows the music, orchestration is like a conductor leading the orchestra.