Multi-region deployment en dataresidentie voor je SaaS: de complete gids

Steeds meer SaaS-bedrijven krijgen te maken met de vraag: waar staan je data eigenlijk? Klanten in de EU willen garanties over dataresidentie, enterprise-klanten eisen specifieke regio's, en regelgeving zoals de GDPR maakt het niet optioneel. In dit artikel duiken we diep in multi-region deployment: waarom je het nodig hebt, hoe je het architecturaal aanpakt, en welke valkuilen je moet vermijden.

Waarom multi-region deployment?

Er zijn drie hoofdredenen waarom SaaS-bedrijven multi-region gaan:

1. Compliance en dataresidentie

De GDPR schrijft voor dat persoonsgegevens van EU-burgers adequaat beschermd moeten worden. Hoewel de GDPR technisch niet vereist dat data in de EU blijft, verwachten veel klanten — vooral in sectoren als gezondheidszorg, finance en overheid — dat hun data in een specifieke regio wordt opgeslagen.

Klant: "Waar staan onze data?"
Jij:   "Eh... ergens in us-east-1?"
Klant: *annuleert contract*

2. Latency en performance

Een gebruiker in Frankfurt die data opvraagt uit een datacenter in Virginia ervaart 80-120ms extra latency per request. Bij een typische paginaload met 5-10 API-calls merk je dat direct.

3. Beschikbaarheid en disaster recovery

Één regio is één single point of failure. AWS us-east-1 heeft meerdere grote storingen gehad. Als je SaaS daar draait en het gaat plat, gaat jouw business ook plat.

Architectuurpatronen voor multi-region

Er zijn drie gangbare patronen, elk met hun eigen trade-offs:

Patroon 1: Regionale isolatie (aanbevolen voor starters)

Elke regio draait als een volledig onafhankelijke stack. Klanten worden bij het aanmaken aan een regio toegewezen en hun data verlaat die regio nooit.

// Voorbeeld: regio-routing bij onboarding
interface TenantConfig {
  id: string;
  region: 'eu-west-1' | 'us-east-1' | 'ap-southeast-1';
  databaseUrl: string;
  apiEndpoint: string;
}

async function createTenant(
  name: string,
  country: string
): Promise<TenantConfig> {
  // Bepaal regio op basis van land
  const region = resolveRegion(country);

  // Maak tenant aan in de juiste regionale database
  const regionalClient = getRegionalClient(region);
  const tenant = await regionalClient.tenant.create({
    data: { name, country, region }
  });

  return {
    id: tenant.id,
    region,
    databaseUrl: REGIONAL_DB_URLS[region],
    apiEndpoint: REGIONAL_API_URLS[region],
  };
}

function resolveRegion(country: string): string {
  const EU_COUNTRIES = ['NL', 'DE', 'FR', 'BE', 'ES', 'IT', /* ... */];
  const APAC_COUNTRIES = ['AU', 'JP', 'SG', 'KR', /* ... */];

  if (EU_COUNTRIES.includes(country)) return 'eu-west-1';
  if (APAC_COUNTRIES.includes(country)) return 'ap-southeast-1';
  return 'us-east-1'; // default
}

Voordelen:

• Eenvoudig te begrijpen en te implementeren
• Volledige data-isolatie per regio
• Compliance is triviaal: data verlaat de regio niet

Nadelen:

• Cross-regio features (zoals globale analytics) zijn complex
• Je beheert meerdere onafhankelijke stacks

Patroon 2: Primaire regio met read replicas

Eén primaire database die schrijfoperaties afhandelt, met read replicas in andere regio's voor snelle leesoperaties.

// Database routing op basis van operatietype
class RegionalDatabaseRouter {
  private primaryClient: PrismaClient;
  private replicaClients: Map<string, PrismaClient>;

  async query<T>(
    operation: 'read' | 'write',
    region: string,
    queryFn: (client: PrismaClient) => Promise<T>
  ): Promise<T> {
    if (operation === 'write') {
      // Schrijfoperaties altijd naar primary
      return queryFn(this.primaryClient);
    }

    // Leesoperaties naar dichtstbijzijnde replica
    const replica = this.replicaClients.get(region)
      || this.primaryClient;
    return queryFn(replica);
  }
}

Let op: dit patroon voldoet niet aan strikte dataresidentie-eisen, omdat alle data uiteindelijk in de primaire regio staat.

Patroon 3: Gedistribueerde database (CockroachDB / YugabyteDB)

Databases zoals CockroachDB ondersteunen natively geo-partitioning: je kunt per tabel of per rij specificeren in welke regio data moet leven.

-- CockroachDB: pin data aan een regio
ALTER TABLE users
  CONFIGURE ZONE USING
    constraints = '[+region=eu-west-1]'
  WHERE country IN ('NL', 'DE', 'FR', 'BE');

ALTER TABLE users
  CONFIGURE ZONE USING
    constraints = '[+region=us-east-1]'
  WHERE country IN ('US', 'CA');

Dit is krachtig maar complex. Gebruik het alleen als je écht globale consistentie nodig hebt.

De routinglaag: hoe komen gebruikers bij de juiste regio?

Een cruciale component is de routing van requests naar de juiste regio. Hier zijn drie benaderingen:

DNS-gebaseerde routing

# Regio-specifieke subdomeinen
eu.app.saasmasters.nl   → EU-west load balancer
us.app.saasmasters.nl   → US-east load balancer
ap.app.saasmasters.nl   → AP-southeast load balancer

API Gateway met tenant lookup

// Centrale gateway die routeert op basis van tenant
import { Router } from 'express';

const router = Router();

router.use(async (req, res, next) => {
  const tenantId = extractTenantId(req);

  // Lookup in globale tenant registry (gecached)
  const tenantRegion = await tenantRegistry.getRegion(tenantId);

  if (tenantRegion !== CURRENT_REGION) {
    // Proxy naar de juiste regio
    const targetUrl = REGIONAL_URLS[tenantRegion] + req.originalUrl;
    return proxy(req, res, targetUrl);
  }

  next();
});

Edge-gebaseerde routing (Cloudflare Workers / Vercel Edge)

// Cloudflare Worker voor intelligente routing
export default {
  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    const tenantId = url.hostname.split('.')[0];

    // Tenant-regio mapping uit KV store
    const region = await TENANT_REGIONS.get(tenantId);

    const origins: Record<string, string> = {
      'eu': 'https://eu-origin.example.com',
      'us': 'https://us-origin.example.com',
      'ap': 'https://ap-origin.example.com',
    };

    // Doorsturen naar juiste origin
    const originUrl = origins[region || 'eu'] + url.pathname;
    return fetch(originUrl, {
      method: request.method,
      headers: request.headers,
      body: request.body,
    });
  }
};

Database-migraties over regio's heen

Een van de lastigste operationele uitdagingen: hoe houd je database-schema's synchroon over meerdere regio's?

// Migratie-orchestrator voor multi-region
class MultiRegionMigrator {
  private regions: RegionConfig[];

  async migrate(migrationFile: string): Promise<void> {
    console.log(\`Migrating \${migrationFile} across \${this.regions.length} regions\`);

    // Stap 1: Valideer migratie in staging-regio
    await this.runMigration('staging', migrationFile);
    await this.validateSchema('staging');

    // Stap 2: Draai migratie per regio, sequentieel
    for (const region of this.regions) {
      console.log(\`Migrating region: \${region.name}\`);

      try {
        await this.runMigration(region.name, migrationFile);
        await this.validateSchema(region.name);
        console.log(\`✓ \${region.name} migrated successfully\`);
      } catch (error) {
        console.error(\`✗ \${region.name} migration failed!\`);
        // Stop direct — los het probleem op voordat je verder gaat
        await this.alertOps(region.name, error);
        throw error;
      }
    }
  }
}

Gouden regels voor multi-region migraties:

• Altijd backward-compatible migraties (geen kolommen droppen in dezelfde release)
• Sequentieel uitrollen, niet parallel
• Automatische rollback-strategie per regio
• Schema-versie tracking in elke regio

Monitoring en observability

Met meerdere regio's wordt monitoring een stuk complexer. Je hebt een gecentraliseerd overzicht nodig:

// Health check aggregator
interface RegionHealth {
  region: string;
  status: 'healthy' | 'degraded' | 'down';
  latencyP99: number;
  errorRate: number;
  activeConnections: number;
  lastCheck: Date;
}

class GlobalHealthMonitor {
  async getStatus(): Promise<RegionHealth[]> {
    const checks = this.regions.map(async (region) => ({
      region: region.name,
      status: await this.checkRegionHealth(region),
      latencyP99: await this.getLatencyP99(region),
      errorRate: await this.getErrorRate(region),
      activeConnections: await this.getConnectionCount(region),
      lastCheck: new Date(),
    }));

    return Promise.all(checks);
  }

  private async checkRegionHealth(region: RegionConfig): Promise<string> {
    const [db, api, cache] = await Promise.all([
      this.pingDatabase(region),
      this.pingApi(region),
      this.pingCache(region),
    ]);

    if (!db || !api) return 'down';
    if (!cache || this.getErrorRate(region) > 0.01) return 'degraded';
    return 'healthy';
  }
}

Kosten: waar moet je op letten?

Multi-region deployment is niet gratis. Dit zijn de belangrijkste kostenposten:

Vuistregel: reken op 1,5-2x je huidige infrastructuurkosten per extra regio.

Stappenplan: van single-region naar multi-region

1. Inventariseer je data — Welke data is regio-gevoelig? Niet alles hoeft gemigreerd.
2. Kies je patroon — Start met regionale isolatie tenzij je een goede reden hebt voor iets complexers.
3. Bouw de routinglaag — DNS of edge-gebaseerd. Test uitgebreid.
4. Migreer je eerste regio — Kies je op-één-na-belangrijkste markt. Houd de primaire regio intact.
5. Automatiseer deployments — Je kunt niet handmatig deployen naar 3+ regio's.
6. Centraliseer monitoring — Eén dashboard, alle regio's.
7. Test failover — Regelmatig. Niet pas als het misgaat.

Conclusie

Multi-region deployment is geen luxe meer voor SaaS-bedrijven die de Europese markt bedienen. Met toenemende regelgeving en hogere klantverwachtingen rond dataresidentie, is het een kwestie van wanneer, niet of.

Start simpel met regionale isolatie, investeer in goede routing en monitoring, en breid uit wanneer je markt daarom vraagt. De initiële investering betaalt zich terug in enterprise-deals die anders onmogelijk zouden zijn.

Het belangrijkste advies: begin met het ontwerp vóórdat je het nodig hebt. Achteraf multi-region toevoegen aan een applicatie die daar niet op gebouwd is, is een van de duurste refactorings die je kunt doen.