Hey developers! 👋
Welcome back to our networking and infrastructure deep-dive series.
In the previous article
we learned something surprising:
Two servers inside AWS, Azure, GCP, or a private datacenter can communicate without touching the public internet.
No ISP.
No public IP.
No internet routing.
Just private networking.
But that raises a much bigger question.
A question every backend developer eventually encounters.
The Mystery Nobody Talks About
Imagine you have:
Web Server
|
|
▼
PostgreSQL Server
Your application needs to connect to PostgreSQL.
Simple.
Right?
Not really.
Because the web server doesn't magically know:
Where PostgreSQL is.
Servers are not humans.
They cannot read dashboards.
They cannot open AWS Console.
They cannot browse Kubernetes UI.
So the real question becomes:
How does one server discover another server?
This seemingly simple question led to the creation of:
- DNS
- Private DNS
- Service Discovery
- Consul
- Eureka
- Kubernetes DNS
- Cloud Map
- Service Meshes
And ultimately became one of the most important problems in distributed systems.
Today we're going deep into that rabbit hole.
Imagine a New City
Suppose you move into a new city.
You need to find:
Hospital
Bank
Police Station
Restaurant
Do you memorize every building's GPS coordinates?
Of course not.
Instead you use:
Names
Such as:
city-hospital.com
instead of:
104.22.18.150
Computers do exactly the same thing.
Humans prefer names.
Networks use IP addresses.
Something must translate between them.
That something is DNS.
DNS: The Internet's Phonebook
DNS stands for:
Domain Name System
Its job is simple:
Name -> IP Address
Example:
google.com
↓
142.250.x.x
When you visit:
https://google.com
your computer first asks:
What's the IP address of google.com?
DNS replies:
142.250.x.x
Only then can the connection begin.
Without DNS:
The internet would be a giant spreadsheet of IP addresses.
Nobody wants that.
What Actually Happens?
When your browser requests:
google.com
the flow looks like:
Browser
|
▼
DNS Resolver
|
▼
Root DNS
|
▼
.com Nameserver
|
▼
Google Nameserver
|
▼
IP Address Returned
Then:
Browser
|
▼
Google Server
Connection established.
This process often completes in milliseconds.
Billions of times every day.
But Cloud Infrastructure Has a Problem
Public DNS works great for public websites.
But what about:
Backend API
Redis
PostgreSQL
RabbitMQ
Elasticsearch
These services are not public.
In fact:
They should NEVER be public.
Example:
api.company.com
can be public.
But:
postgres.company.com
should almost never be exposed to the internet.
So where do we keep internal server names?
This is where Private DNS enters the picture.
Private DNS: The Hidden Phonebook
Think of Private DNS as:
An internal company directory.
Only employees can access it.
Not outsiders.
Example:
db.internal
redis.internal
auth.internal
payments.internal
These names resolve only inside the private network.
Outside users see:
Nothing.
Inside AWS this is common.
Example:
ip-10-0-4-25.ec2.internal
or
db.production.internal
Only resources inside the VPC can resolve these names.
The public internet has no idea they exist.
Real Production Example
Suppose you're building an e-commerce platform.
Architecture:
Internet
|
▼
Load Balancer
|
▼
Web Servers
|
▼
API Service
|
├────────► PostgreSQL
|
├────────► Redis
|
└────────► RabbitMQ
Question:
How does API Service find PostgreSQL?
Do we hardcode:
10.0.12.55
inside the application?
Never.
Because servers change.
Instances restart.
Containers move.
Databases failover.
IP addresses evolve.
Hardcoded IPs become operational nightmares.
Instead:
DATABASE_HOST = "postgres.internal"
Now infrastructure can move PostgreSQL anywhere.
DNS updates.
Application remains unchanged.
Beautiful.
The IP Address Problem
Modern infrastructure is dynamic.
Very dynamic.
Consider Kubernetes.
A container crashes.
A new container starts.
The new container may receive:
Completely different IP
within seconds.
Imagine every service storing IPs manually.
The system would collapse.
This is why names matter.
Names remain stable.
IPs do not.
Enter Service Discovery
DNS solved:
Find a machine
Service Discovery solves:
Find a service
Those sound similar.
They are not.
Let's see why.
The Microservice Nightmare
Imagine:
User Service
Order Service
Payment Service
Notification Service
Inventory Service
Recommendation Service
Each service runs:
Multiple Instances
Example:
Payment Service
payment-1
payment-2
payment-3
payment-4
Now User Service wants Payment Service.
Which instance should it choose?
payment-1 ?
payment-2 ?
payment-3 ?
payment-4 ?
Hardcoding doesn't work.
Static DNS doesn't fully solve it.
We need something smarter.
What Service Discovery Actually Does
A service registry keeps track of:
Who exists
Where they are
Whether they are healthy
Think of it like:
Air Traffic Control
for services.
Every service announces:
I'm alive.
Here's my address.
Registry stores that information.
Other services ask:
Where is Payment Service?
Registry responds:
payment-2
payment-3
payment-4
Now requests can flow.
Netflix Solved This Years Ago
When Netflix moved to microservices they faced a huge challenge.
Thousands of services.
Millions of requests.
Servers constantly scaling.
They created:
Eureka
A service discovery platform.
Services register themselves.
Other services discover them dynamically.
Without manual configuration.
This became one of the foundational patterns of cloud-native architecture.
Kubernetes: Service Discovery on Steroids
Kubernetes has built-in service discovery.
Suppose you deploy:
payment-service
with:
4 Pods
Kubernetes automatically creates:
payment-service.default.svc.cluster.local
Your application simply uses:
PAYMENT_URL = "http://payment-service"
No IP required.
No server management.
No lookup tables.
Kubernetes DNS handles everything.
Behind the scenes:
payment-service
|
▼
Cluster DNS
|
▼
Healthy Pods
Magic?
Not really.
Just extremely sophisticated automation.
What Happens During a Request?
Imagine:
Order Service
calls:
Payment Service
Flow:
Order Service
|
▼
DNS Query
|
▼
Cluster DNS
|
▼
Payment Service Endpoints
|
▼
Healthy Pod Selected
|
▼
Request Sent
All this happens in milliseconds.
Most developers never see it.
Yet every request depends on it.
Health Checks Change Everything
Modern service discovery isn't just:
Where is the service?
It also asks:
Is the service healthy?
Suppose:
payment-3
crashes.
Registry detects failure.
Immediately removes it.
Now traffic goes only to:
payment-1
payment-2
payment-4
No code changes required.
No deployment required.
Infrastructure heals itself.
This is one of the superpowers of modern cloud systems.
DNS vs Service Discovery
Many engineers confuse them.
Let's simplify.
| Feature | DNS | Service Discovery |
|---|
| Finds Machines | Yes | Yes |
| Finds Services | Limited | Yes |
| Tracks Health | No | Yes |
| Dynamic Scaling | Limited | Excellent |
| Cloud Native | Partial | Yes |
| Microservices Friendly | Partial | Excellent |
Think of DNS as:
A phonebook
Think of Service Discovery as:
A live GPS system with traffic updates.
Huge difference.
AWS Example
AWS provides:
AWS Cloud Map
Services register themselves.
Applications discover services dynamically.
Instead of:
10.0.22.17
you use:
payment.production.internal
AWS continuously keeps records updated.
Your applications stay clean.
Infrastructure stays flexible.
The Hidden System Every Developer Uses
Whenever your application connects to:
Database
Cache
Queue
API
Microservice
one of the following is usually working behind the scenes:
DNS
Private DNS
Service Discovery
Without them:
Modern cloud architecture would be impossible.
Not difficult.
Impossible.
Visual Mental Model
Application
|
▼
Service Name
(payment-service)
|
▼
DNS / Service Discovery
|
▼
Healthy Instance
(payment-2)
|
▼
TCP Connection
|
▼
Response
Simple.
Powerful.
Cloud Native.
Why System Designers Care
Junior developers often think:
Database Host = Some String
System designers think:
How is that string resolved?
Who owns it?
What happens during failover?
How is health tracked?
How does scaling affect discovery?
How quickly do updates propagate?
These questions separate:
Application Development
from
Infrastructure Engineering
Understanding service discovery is one of the first steps toward thinking like a platform engineer, DevOps engineer, cloud architect, or distributed systems designer.
TL;DR Quick Recap
- Servers communicate using IP addresses.
- Humans prefer names.
- DNS translates names into IP addresses.
- Private DNS provides internal-only naming.
- Modern infrastructure avoids hardcoded IPs.
- Service Discovery tracks service locations dynamically.
- Kubernetes provides built-in service discovery.
- Healthy instances are automatically discovered.
- Failed instances are automatically removed.
- Every modern cloud platform depends heavily on these mechanisms.
Final Thoughts: The Invisible Map of the Cloud 🗺️
Most developers spend years writing:
DATABASE_HOST="postgres"
without asking:
Who told the application where postgres is?
Behind that tiny configuration value sits an enormous ecosystem:
- DNS Servers
- Private DNS
- Service Registries
- Health Checks
- Load Balancers
- Cloud Networking
- Kubernetes Controllers
All working together to answer one deceptively simple question:
"Where is the thing I'm trying to talk to?"
And surprisingly, that question powers almost every distributed system on Earth.
In the next article, we'll go even deeper:
How Does Traffic Know Which Server Should Receive the Request?
Load Balancers → Reverse Proxies → Traffic Routing → Health Checks
Because finding a service is only half the story.
Choosing the right instance is where things get really interesting. 🚀