Data Residency Patterns
Meridian routes inference traffic across multiple regions while keeping customer payloads inside the jurisdictions they were collected in. This recipe walks through three production-grade residency patterns used by teams shipping to EU, US, and APAC tenants on a single deployment.
01.Region-pinned routing
Pin every request to a regional gateway based on the tenant claim in the JWT. Meridian reads x-meridian-regionand forwards traffic to the matching upstream pool. No payload bytes ever cross a region boundary, including logs and trace spans.
- EU tenants route through eu-central
- US tenants route through us-east
- APAC tenants route through ap-southeast
02.Encrypted regional caches
Prompt-cache entries are scoped to the region that produced them and encrypted with a region-local KMS key. A US cache hit on an EU prompt is impossible by construction since the cache key namespace embeds the region tag during the SHA-256 derivation step.
// meridian.ts
import { Meridian } from "@meridian/sdk";
const client = new Meridian({
apiKey: process.env.MERIDIAN_KEY,
region: "eu-central",
residency: {
pinCache: true,
logRegion: "eu-central",
auditSink: "s3://meridian-eu-audit"
}
});
const reply = await client.chat({
model: "azure/model-router",
messages: [{ role: "user", content: input }]
});03.Audit and egress controls
Every routed call lands in a regional audit sink that the tenant can attach to their own bucket. Meridian never replicates audit rows across regions. Egress to a foreign region requires an explicitcross_region_ok: trueflag plus a signed operator approval.