Skip to content

PATTERN Cited by 1 source

Explicit placement hint

Intent

Pin a serverless / edge compute unit to a specific region — overriding the platform's default user-proximity routing — so the compute runs adjacent to a stateful dependency (typically a centrally-located database) and the chatty compute-to-state round-trips stay within datacentre-scale RTT.

Configuration shape from Cloudflare Workers (Source: sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers):

{
  "placement": { "region": "aws:us-east-1" }
}

Context

Edge runtimes default to running compute as close as possible to the user who made the request — which minimises the client-to-edge leg of the latency budget. That heuristic is the wrong answer when the critical path is dominated by compute-to-origin-database traffic rather than compute-to- user traffic (see concepts/edge-to-origin-database-latency):

  • A request that issues N SQL queries to a central Postgres / MySQL pays N × RTT from the edge POP to the DB region.
  • Running in the user-nearest POP minimises user-facing response body start time but inflates each SQL RTT.
  • Running in the DB-nearest POP reverses the trade: SQL RTTs collapse to intra-DC latency; the user-to-edge leg is slightly longer but amortised once across many SQL hops.

For single-query workloads the default wins; for multi-query workloads the DB-pinned placement wins.

Solution

Expose a per-application configuration knob that lets the developer declare the fixed-location dependency and force the edge platform to ignore user-proximity routing in favour of dependency-proximity routing.

Shape on Cloudflare Workers:

{
  "placement": {
    "region": "aws:us-east-1"
  }
}
  • The region token maps to cloud-provider + region pairs (aws:us-east-1), letting the hint target the same region the customer's managed DB lives in.
  • The hint is declarative — the runtime still decides which specific POP within the region serves the request; the knob only constrains which region is eligible.
  • It is per-Worker, not per-request — the full deployment runs in the hinted region.

Variants and evolution

  • Manual hint (today): customer writes placement.region by hand in wrangler.jsonc. Works, but requires the developer to keep Worker config in sync with DB region.
  • Auto-placement from provisioning context (forward- looking for Cloudflare × PlanetScale): "In the future, Cloudflare can automatically set a placement hint based on the location of your PlanetScale database and reduce network latency to single digit milliseconds." When the platform also provisions the DB (as with the PlanetScale dashboard integration), it knows the DB region and can set the placement hint without explicit customer configuration (Source: sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers).

The evolution follows the general platform arc: start by exposing a manual knob, observe that the platform knows the right value, move the knob inside the platform.

Consequences

Positive

  • Collapses multi-query SQL latency tail from cross-region RTT to intra-DC RTT (single-digit ms target).
  • Pairs cleanly with systems/hyperdrive: pooled + cached connections reduce number of RTTs; placement reduces cost of each RTT.
  • Natural fit for agent-chain workloads where a single task issues many dependent queries.

Negative

  • User-nearest-POP latency advantage is sacrificed for the static content / simple request path — may require splitting the workload across differently-placed Workers if the same deployment serves both SQL-heavy and cache-heavy paths.
  • Creates a single regional blast radius — if the DB region is unreachable, the Worker is too, regardless of how global the CDN underneath is.
  • Obsoletes the platform's adaptive routing for that Worker; you're committing to a manually-managed region choice until auto-placement fills in.

Known uses

Last updated · 200 distilled / 1,178 read