When a customer opens Tiffin, the app's first job is to call api.tiffin.app. But the network doesn't route names. It routes numbers. Before a single byte of the request can leave the phone, something has to turn api.tiffin.app into an address like 203.0.113.42.
That something is DNS, the Domain Name System. It's one of the oldest and most reliable pieces of the internet, and it's quietly involved in load balancing, failover, CDNs and service discovery. It's also behind some of the biggest outages in history. This lesson covers how a lookup actually works, why it's usually fast, and how DNS shows up in your designs.
Prerequisites in one paragraph. A client (the Tiffin app) sends a request to a server, which talks to a database and sends a response back (see Module 2, "The life of a request"). That request first needs an IP address. This lesson is about that first step.
A name is not an address
DNS is a distributed, cached directory that maps names people can remember to records machines can use, most often IP addresses.
Two things in that sentence matter.
Distributed. No single server knows every name. The data is split by the dots in the name. One set of servers knows who runs .app. The .app servers know who runs tiffin.app. Tiffin's own DNS provider knows the address of api.tiffin.app.
Cached. Almost every answer is remembered somewhere for a while. That's why DNS is fast, and it's also why DNS changes are slow to spread.