# What is service discovery?
* A key problem in deployment is getting services to be able to find each-other
* A database might be at 10.1.1.1:6543 while the webserver is at 10.1.1.2:8080
### Level 1 Service Descovery: Baiscs
* Everything is manually configured
{% hint style="warning" %}
You'll know you should start caring about service discovery when you start seeing one of the following:
1. You want "zero downtime deployments" or to use other, more complex deploy strategies
2. You have more than a couple of microservices
3. You are deploying to several environments (dev, staging, prod) and it's getting unwieldy
{% endhint %}
### Lever 2: Service Discovery via hash table
* A straightforward approach: Store the service IPs in a hash table
* The hash table in question in the config is here:
{% hint style="info" %}
In simple term:
* All you need to do is update your frontend to set the keys in the hash table to be the forntend's IP
* Then make the backend do the same for the backend
{% endhint %}
#### Problems with this approach
* It's complex
* It's error prone
* It requires to write custom config files
### Level 3 Service Discovery via DNS
* The idea for DNS is just to map hostnames to IPs. This is the industry standard
* It would be ideal if we could connect to "" from our reverse proxy and having DNS respond with the IP for the correct versions of the frontend
* So instead of the first example where you use the IP
* You would use `mongo` where `mongo` is a key in the key:value pairs
