Client-Server and DNS

Build the mental model

Before any request reaches an application server, it has to solve a more basic problem: computers communicate over IP addresses, but humans type domain names. DNS (Domain Name System) is the lookup that bridges the two — when a browser needs to reach example.com, it asks a DNS resolver to translate that name into an IP address, and only then can it open a network connection to the actual server at that address. This resolution step is invisible in normal use but happens before literally every web interaction, and it isn't free: a full DNS lookup can add real, noticeable delay, especially across long network distances. To make this fast, DNS results are cached — locally in the browser or OS, and at intermediate resolvers — for a duration set by the record's TTL (time to live). A short TTL means changes to where a domain points propagate quickly but the lookup happens often; a long TTL means faster repeat lookups but slower propagation if the underlying server address ever changes. This client-to-server path — resolve, then connect — is the baseline architecture every other lesson in this course builds on top of.

Connect it to a real scenario

Every time a learner types the Tutorial Platform's domain into a browser, DNS resolution happens before a single byte of lesson content loads — and it's part of why the platform's engineers care about TTL settings, not just server code. If the platform ever needs to move to a new server (say, during the horizontal-scaling rollout from the last lesson), a long DNS TTL means some learners keep hitting the old server for hours after the switch, while a short TTL lets the change propagate fast but costs more lookups per second at scale. Understanding this path is the foundation every later lesson — load balancing, caching, replication — sits on top of.

Every web request starts with DNS resolution: translating a human-readable domain name into a numeric IP address before any connection is made.
DNS results are cached at multiple layers (browser, OS, resolver) for a duration set by TTL, trading propagation speed against lookup frequency.
Client-server communication is: resolve the domain via DNS, then open a connection to the server at the resolved IP — the baseline every other system design concept builds on.

Try the working example

text

Browser                DNS Resolver            IP Address           Server
--------                ------------            ----------           ------
  |  "example.com?"          |                       |                  |
  |------------------------->|                       |                  |
  |                          | [check cache: MISS]    |                  |
  |                          |----------------------->|                  |
  |                          | 93.184.216.34, TTL=300s|                  |
  |<-------------------------|                       |                  |
  |  [cache IP for 300s]     |                       |                  |
  |------------------------- connect to 93.184.216.34 ------------------>|
  |                                                                       |
  |  Next request (within 300s): skip DNS lookup entirely, use cached IP |

You should see

The diagram shows DNS resolution — including the cache check and TTL — happening before the actual connection to the server is opened.

5-minute try-it

Run nslookup or dig against a website in your terminal and find the returned TTL value — what would a short vs long TTL mean for that site's owner?

One important caution

Setting a very long DNS TTL for convenience, then discovering during a server migration or outage that a large share of clients keep sending traffic to the old, now-broken IP address for hours.

Assuming DNS resolution is instantaneous and free, when in reality an uncached lookup adds real latency — especially damaging for a request path where every millisecond of latency budget already matters.

Wikipedia — Domain Name System — System Design