A team proposes moving an API to edge functions to reduce latency for international users. What do you check before agreeing?

Where is the data?

This is the question that settles most edge proposals. Compute at the edge that calls back to a single-region database has moved the compute and not the data: the request now travels to the nearest edge, then to the origin region and back, which is the same round trip plus an extra hop.

Edge helps when the response can be produced at the edge — from cached content, from replicated read-only state, or from a computation needing no origin call.

What fraction of the response is cacheable or replicable?

If the API is read-heavy over data that tolerates a second of staleness — configuration, catalogue, pricing, feature flags — edge replication works and the latency gain is real.

If every response is personalised and derived from a transactional store, it does not, and the honest options are a read replica in each region or accepting the latency.

Does the runtime support what the API does?

Edge runtimes are constrained by design: restricted APIs, tight memory, limited execution time, no persistent local state, often no native code, and typically no conventional database connection pool. An API needing any of those is not a candidate.

Cold start is also a common path rather than a tail case at the edge, because traffic is spread across many locations so each sees a fraction.

What is the actual latency budget?

Measure the current end-to-end split: network, origin processing, data access, rendering. If origin processing dominates, edge placement changes little and the effort belongs elsewhere.

What it looks like when it is right

Reads served from a local replica in single-digit milliseconds; writes forwarded to one authoritative region. Which then requires handling read-your-own-writes — a user who saves and immediately reloads may hit a replica without their change, and will conclude the save failed. Pin the session briefly, read from the authoritative region after a write, or reflect the change from client state.

That case is not an edge case; it is every write, and it is what a proposal should address before it is agreed.