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 9-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”
In the world, your application runs on a known server at a known IP address. Configuration is simple: the database is at 10.0.1.5:5432, the cache is at 10.0.1.6:6379. These addresses rarely change.
In , everything moves. The Payment Service had 3 instances yesterday, 8 today, and 5 tomorrow. Instances die and respawn on different machines with different IP addresses. You deploy a new version, old instances shut down, new ones start on random ports. An auto-scaler adds 10 instances during peak traffic and removes them at 3 AM.
If the Order Service needs to call the Payment Service, what IP address does it use? Hardcoding addresses is impossible when everything is in constant motion. You need a phone book that updates itself in real time. That's service discovery.
Netflix runs 700+ microservices across thousands of ephemeral EC2 instances. During a single deployment, hundreds of instances might swap out. Eureka, their service discovery system, handled 10 million lookups per minute to keep everything connected. Without automated discovery, Netflix's architecture would collapse.
Client-Side Discovery: The client queries a service registry to get a list of available instances, then picks one using a load-balancing algorithm (round-robin, random, least-connections).
| Step | What Happens |
|---|---|
| 1. Registration | Payment Service instances register themselves with the registry on startup |
| 2. Heartbeat | Each instance sends periodic heartbeats; registry removes unresponsive ones |
| 3. Lookup | Order Service asks the registry: "Where is Payment Service?" |
| 4. Selection | Order Service picks one instance from the list and calls it directly |
Examples: Netflix Eureka + Ribbon, HashiCorp Consul with client-side routing.
Server-Side Discovery: The client sends requests to a or router, which queries the registry and forwards the request to an available instance. The client doesn't know about the registry at all.
Examples: AWS Elastic Load Balancer + ECS, Service + kube-proxy, Nginx with Consul integration.