Residency-first placement, and why latency comes second

Every workload scheduler we evaluated optimises for latency and cost, then expects you to pin workloads to regions by hand to satisfy residency.

That is backwards. Latency is an optimisation with a gradient — 40ms is worse than 20ms but both work. Residency is a cliff. Either the data is in the permitted jurisdiction or you are in breach.

Constraints, then optimisation

Our scheduler takes residency as a hard constraint and solves for latency inside the permitted set:

residency:
  required: [ng]        # hard — never violated
latency:
  target_p99_ms: 90     # soft — optimised within the above

If no placement satisfies the hard constraint, you get told which constraint is binding at deploy time. You do not get a working deployment that is quietly unlawful.

The cross-border case

It gets harder when a workload legitimately spans jurisdictions — a settlement engine reconciling Nigerian and Ghanaian transactions. There, the unit of residency is the record, not the workload, and the scheduler has to split execution rather than place it.

That is the part that took eighteen months.