A VP says the app feels slow in Asia and asks whether the team should move it to the edge. Walk me through how you scope that conversation.

What the interviewer is testing

Whether you decompose the latency before proposing an architecture. "Move it to the edge" is a solution to several different problems and a solution to none of them in general, and the strong answer is a measurement plan that turns one complaint into three numbers.

The clarifying questions that change the answer

• What is slow: first byte, first render, or one particular API call? These have different fixes and only one of them is an edge problem.
• What fraction of the time is network versus rendering? A client-side bundle problem does not improve by moving the origin.
• Is it the first visit or every visit? Cold-connection cost is paid once per connection, so a first-visit problem and a steady-state problem are different diagnoses.
• Reads or writes? Writes must reach the authority, and no edge deployment changes where the authority lives.
• Is the data replicable, and is any of it residency-constrained?

A strong answer's arc

1. Do the arithmetic first. A round trip between Singapore and the US east coast is on the order of 200 ms. A cold connection costs a TCP handshake plus a TLS handshake — several round trips — before the first byte, so the first request on a new connection can spend 400 to 600 ms in handshakes alone.
2. Take the free win. Terminating TLS at a nearby edge and holding warm pooled connections back to the origin removes those handshake round trips, even though the data still crosses the ocean. It requires no application change and is usually the single largest improvement available.
3. Then cache what is cacheable, with tags rather than URL purges, including personalised fragments assembled at the edge from a cacheable shell.
4. Then move read-only logic, backed by a replicated key-value store at the edge, for things like routing rules, feature flags and pricing tiers.
5. Only then consider regional write paths, which means a regional database with all the consistency and residency questions that implies. This is the expensive step and it should be justified by a measured write-latency problem, not by the word "edge".

Common weak answers

• "Deploy the app as edge functions." Edge runtimes have tight CPU and memory limits per request, restricted libraries, no long-lived connections and a cold-start profile of their own. Moving an application there is a rewrite, not a deployment target.
• "Add a region in Singapore." Reasonable and incomplete: if the database stays put, you have moved the compute away from the data and made every query a round trip.
• Quoting a competitor. A marketplace in the mould of Grab has a traffic shape dominated by frequent short writes from mobile clients, which is nearly the opposite of a read-heavy content site. The right topology follows the read/write mix, not the logo.

What a strong answer adds

The operational bill. A second runtime means a second deployment path, a second set of limits to learn, and debugging spread across many points of presence where a single user's session may touch a different one each request. Ask what the team will stop doing to pay for that, and propose the staged sequence above so that most of the benefit arrives before most of the cost does.