We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 11-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Two ways to coordinate a group of performers:
An orchestra has a conductor. The conductor has the full score. They tell the violins when to start, the trumpets when to come in, and the drums when to crescendo. Every musician follows the conductor's instructions. The conductor knows the entire plan.
A dance floor has no conductor. Each dancer reacts to the music and to the movements of nearby dancers. Nobody has the full plan. The emergent behavior, everyone moving in harmony, comes from each dancer following simple, local rules. No one person controls the whole.
In , these correspond to orchestration (a central coordinator tells each service what to do and when) and choreography (services react to events independently, with no central coordinator).
Both are valid. Both are used in production at scale. The right choice depends on the complexity of your workflow, the coupling you can tolerate, and where you want the logic to live. Most production systems at companies like Uber, Netflix, and Amazon use both, for different workflows.
In orchestration, a central coordinator (the orchestrator) manages the workflow. It knows the sequence of steps, calls each service in order, handles errors, and manages the overall state.
Example: Order processing with orchestration:
| Step | Orchestrator Does | Service Does |
|---|---|---|
| 1 | Calls Payment Service: "Charge $50" | Charges the card, returns success |
| 2 | Calls Inventory Service: "Reserve items" | Reserves items, returns success |
| 3 | Calls Shipping Service: "Create shipment" | Creates shipment, returns tracking ID |
| 4 | Calls Notification Service: "Send confirmation" | Sends email |
| Error | If step 2 fails, calls Payment Service: "Refund $50" | Refunds the charge |
The orchestrator holds the entire workflow definition. It knows what comes after what, what to do on failure, and the current state of each order. Services are simple workers. They do what they're told.
Tools: Temporal (code-based workflows in Go/Java/TypeScript), AWS Step Functions (JSON state machine), Netflix Conductor (JSON + custom workers), Camunda (BPMN diagrams), Apache Airflow (Python DAGs, primarily for data workflows).
Uber built Cadence (the predecessor to Temporal) because choreography couldn't handle the complexity of ride matching. A single ride involves pricing calculation, driver matching, driver notification (15-second timeout), payment authorization, fraud detection, and route optimization. That's 6+ services with conditional branching, timeouts, and compensation at every step. Without an orchestrator, debugging a failed ride required correlating events across a dozen service logs.