advanced 4 min answer

An interviewer says - our p99 is 180 ms for users near our single region in Europe and over 2 seconds for users in Brazil. There is no budget for a second region this year. What do you do?

latencyround tripsedgetlscdn
Show the full answer Hide the answer

What the interviewer is testing

Whether you reach for architecture before physics. The round trip from Brazil to Western Europe is roughly 180 to 220 ms and nothing on the engineering side changes it. A candidate who proposes a second region has answered a different question - the budget was stated as a constraint - and a candidate who says "add a CDN" without saying what it caches has not engaged with a dynamic workload.

The real content is counting round trips and removing them.

The clarifying questions that change the answer

  • How many round trips does a cold page load take today? DNS, TCP, TLS and then the request: that is already four round trips before a byte of content, which at 200 ms each is 800 ms spent on handshakes.
  • Is the slow path reads or writes? Reads can be served near the user. A write must reach the region of record, and that cost is irreducible without changing the consistency model.
  • What is the session shape? A single request per visit is a different problem from 30 requests over ten minutes, where connection reuse dominates.
  • How stale may data be? Seconds of staleness buys a cache; zero staleness buys nothing.

A strong answer's arc

  1. Terminate TLS and TCP at an edge location near the user. This is the highest-value change available and it needs no second region: the handshakes complete in 20 ms locally, and the edge holds a warm, multiplexed connection back to origin. Four round trips at 200 ms become one at 200 ms plus three at 20 ms.
  2. Cache what can be cached, and say which. Static assets obviously. Then the surprising half: API responses with short TTLs, personalised fragments assembled at the edge, and anything behind stale-while-revalidate, which lets the user get an instant answer while the edge refreshes behind them.
  3. Cut round trips in the application. Eight sequential calls at 200 ms is 1.6 seconds of nothing but waiting; collapse them into one request, or parallelise them. This is usually the single biggest win in the application's own control, and it is free.
  4. Use the protocol features. HTTP/2 or HTTP/3 to multiplex, TLS session resumption and 0-RTT for repeat visitors, and early hints so the browser fetches assets during the server's think time.
  5. Shrink the payload. At 200 ms RTT, every extra round trip caused by a large response and a small congestion window costs more than the bytes do. Compression and smaller critical-path payloads buy more in Brazil than anywhere else.
  6. Then the honest part: state what remains irreducible - writes, and anything requiring a read-after-write from the region of record - and put a number on it, so next year's second-region business case is a measurement rather than an argument.

Common weak answers

  • "Add a CDN." Correct and incomplete. The value for a dynamic application is TLS termination and connection reuse, not asset caching, and saying so is what distinguishes a considered answer.
  • "Use a faster network provider." The speed of light in fibre is about 200,000 km/s; the route is already close to geodesic. Private backbones help with loss and jitter, not with distance.
  • "Replicate the database to Brazil read-only." Plausible and it is a second region wearing a smaller hat, with the budget and consistency questions intact.

When the physics wins anyway

Two things on this list fail quietly and should be named before they are built. Edge termination moves the TLS handshake and not the request, so a page that makes 8 sequential API calls is still 8 x 200 ms because each one waits for the last; the application change has to come with it or the edge buys 600 ms once and nothing after. And 0-RTT resumption is not free of risk: early data can be replayed, so it is safe for idempotent reads and must be refused for writes - HTTP/3 (RFC 9114, 2022) and TLS 1.3 both make that the implementer's responsibility rather than the protocol's.

What a strong answer adds

Measurement and sequencing: synthetic checks from Brazil before and after each change, so the improvements are attributed rather than claimed; a per-change estimate in round trips rather than in milliseconds, which is the unit that travels; and an explicit note that the first change - edge termination - also reduces origin load, which is the argument that gets it funded without a regional budget line.