How do you set a policy for which routes run near users and which stay in the data's region, and when do you revisit it?

## Start from the default, not the exceptions Most of the latency outcome of an app is decided by which placement is the default, because most routes never get individually considered. The safe default is **the region where the data lives**. It is the placement that is never catastrophically wrong: a route with no reads is only slightly slower there than it would be near the user, while a read-heavy route near the user can be several times slower than it would be in the region. Asymmetric risk argues for the conservative default and a promotion process for the exceptions. The promotion process is what the policy actually is. ## Four questions before a route is promoted 1. **How many round trips does it make before its first byte?** Zero is a clear yes. One is a measurement. Several dependent ones is a no until the route is restructured. 2. **Does its code fit the target?** Near-user execution commonly means a constrained, web-standard-only environment with hard ceilings on CPU, memory and bundle size. A route whose dependency tree assumes a full runtime is not a placement decision at all — it is ineligible until that dependency is replaced. 3. **Is there enough traffic per location?** Anything the route caches or warms is per location. A thin audience spread over many locations keeps each one cold, which can cancel the gain on everything but request-only work. 4. **Can we operate it there?** The near-user runtime has no durable disk and no attachable process, and a page view arrives as several unlinked invocations. If the team cannot yet see into it, only trivially diagnosable work belongs there. | signal | keep it in the data's region | promote it near users | |---|---|---| | data round trips before first byte | one or more, especially dependent | none | | response shape | personalised per user, freshly read | derived from the request alone | | dependency tree | needs a full runtime | web-standard APIs only | | traffic density | thin and scattered | steady in each served geography | | failure cost | high, and needs deep diagnosis | low and self-evident | ## Keep the decision reversible The policy is worth little if acting on it is expensive. Placement should be a declaration attached to a route — a setting the deployment reads — not something the route's structure encodes. Two things follow. First, a wrong decision costs a line and a deploy to undo, which means teams will actually correct them. Second, moving a route back becomes a legitimate diagnostic: same code, same data, one variable changed. The review trigger matters as much as the criteria. The common failure is not a bad initial decision but a silent drift: a request-only handler near the user gains its first data call in an ordinary feature change, and nobody re-asks the question. Make “this route is near the user and now reads data” something a reviewer is expected to notice, and keep the placement declaration close enough to the route that it is visible in the same diff. ## Measure by geography and percentile A global average latency is the worst instrument for this decision: it mixes the users who gained with the users who lost, and near-user placement changes both groups in opposite directions. Judge it by high percentiles per geography, before and after, with the data in its real region. It is normal and acceptable for a promotion to help a distant continent substantially while slightly hurting the users who sat next to the original region — as long as that trade was made knowingly. ## The cost you are actually buying Running two placements is an organisational choice, not only a technical one: - two sets of runtime constraints that library choices must satisfy; - two debugging stories, and engineers who need both; - a build that must produce output for two targets; - a class of bug that appears only in one of them. For an app whose audience is concentrated where its data already is, the honest answer may be that no route should be promoted at all. For a globally distributed audience with meaningful request-only work — routing decisions, variant selection, access gating — the split pays for itself. A lead's job is to make that call explicitly rather than inheriting it from a default. ## When to revisit - The data moved, or gained a second home. - A promoted route acquired a read, or a pinned route lost its last one. - The audience shifted geographically, or traffic density per location changed materially. - The platform's ceilings or runtime changed what is eligible. - An incident showed the diagnosis cost of a near-user route to be higher than assumed.