Belajar Staff Engineer - Multi-Region & Data Residency

#Pendahuluan

Setelah di episode 19 kita menavigasi compliance lewat kontrol otomatis dan audit trail, pada episode ini kita hadapi keputusan arsitektur yang paling mahal untuk diputar balik: multi-region & data residency. Ketika pelanggan Eropa minta datanya tinggal di EU, regulator Indonesia mensyaratkan PDP, atau bisnis ekspansi ke Asia tapi pengguna komplain latensi — kalian adalah orang yang memutuskan bagaimana sistem menghadapinya.

Ini topik yang penuh jebakan biaya: multi-region bisa melipatgandakan tag cloud tanpa menambah nilai, atau memecah data sedemikian rupa hingga fitur sederhana menjadi mimpi buruk konsistensi. Kita bedahkan cara berpikirnya secara bertahap.

#Klasifikasi Data Dulu, Arsitektur Belakangan

Kesalahan umum: langsung bertanya "replikasi mana yang tepat?" sebelum tahu data apa yang bicara. Mulailah dari inventaris (fondasi episode 19):

Dari klasifikasi lahir keputusan region pinning: data kelas PII milik pelanggan EU hanya disimpan dan diproses di region EU — bukan "direplikasi global dengan enkripsi tambahan" (yang secara hukum sering tetap transfer lintas batas).

Aturan praktis yang menyelamatkan banyak organisasi: minimalkan permukaan data yang butuh pinning. Semakin banyak sistem yang menyentuh PII, semakin besar wilayah yang harus direplikasi per-region. Refactor agar layanan inti non-PII global sementara data identitas terkonsentrasi di beberapa service sempit.

#Pola Arsitektur Multi-Region

Empat pola umum, diurutkan dari termurah:

#1. Active-Passive (DR Saja)

Satu region aktif melayani; region kedua siaga untuk disaster recovery dengan replikasi asinkron. Murah (region pasif tak menerima traffic), cocok saat motivasi utama ketahanan bencana, bukan latency atau regulasi.

#2. Global Front Door + Regional Data

Edge/CDN dan stateless layer global; data tetap satu region. Menurunkan latensi read statis tanpa masalah konsistensi. Batasnya jelas: tidak menyelesaikan kebutuhan residency data dinamis.

#3. Read Replicas Regional

Data master satu region; replica read di region lain. Query baca lokal cepat, tulisan tetap lintas region (~100-300 ms). Cocok untuk workload baca-dominan yang toleran staleness singkat.

#4. Cell-Based / Shard-by-Jurisdiction

Setiap region punya stack lengkap dengan subset pengguna (pelanggan EU → cell EU). Tidak ada replikasi lintas batas data PII; konsistensi global tidak dibutuhkan karena tiap cell mandiri. Inilah pola yang realistis untuk kebutuhan residency keras — dengan harga: routing pengguna, operasi n-cell, dan fitur yang menyentuh lintas cell harus dirancang ulang.

Perhatikan global catalog di diagram: metadata non-PII (listing produk, konfigurasi) boleh global — inilah yang menjaga fitur lintas region tetap mungkin.

#Trade-off Latency vs Compliance vs Biaya

Tidak ada opsi gratis. Matriks keputusan ringkas:

Dua pertanyaan penyaring sebelum memilih:

1. Apakah ada regulasi yang benar-benar mewajibkan? Banyak kepanikan "GDPR!" ternyata bisa diselesaikan dengan SCC/transfer mechanism legal — tanya tim legal sebelum merancang ulang dunia.
2. Apakah latensi nyata masalah bisnis? Ukur distribusi pengguna dan dampak latensi pada konversi; kadang CDN + cache menyelesaikan 90% keluhan dengan 5% biaya multi-region.

#Desain Residency yang Bisa Dieksekusi

Untuk organisasi mid-size, jalur realistis biasanya bertahap:

1. Fase 0 — inventaris & klasifikasi: manifest data per layanan dengan flag residensi (dibangun di episode 19).
2. Fase 1 — kurangi permukaan PII: konsolidasikan PII ke service identitas; hapus salinan liar (log, cache, export) yang sering lupa ikut aturan.
3. Fase 2 — region pinning untuk kelas wajib: deploy stack identitas + transaksi di region target dengan isolasi penuh; sisanya tetap global.
4. Fase 3 — routing & lifecycle: routing pengguna by-jurisdiction, provisioning per-region, serta proses deletion/export untuk hak subjek GDPR/PDP.

Detail fase 4 yang sering bocor: lifecycle data. Residency bukan cuma soal tempat simpan — backup, log, dan analytics pipeline juga membawa data. Backup database EU ke bucket global = pelanggaran halus yang baru ketahuan saat audit. Aturan praktis: setiap artefak turunan data PII mewarisi residensinya.

#Praktik: Dokumen Residency Design

Susun ~/staff-lab/initiatives/residency-design.md:

# Residency Design: Ekspansi EU (Q4)
 
## Driver
- Kontrak enterprise EU mensyaratkan data di region EU.
- Legal: transfer mekanisme SCC dinilai tidak cukup untuk
  klaster pelanggan ini (bukan sekadar preferensi).
 
## Klasifikasi (ringkas)
Pinned   : identity-db, orders-db, audit-log EU users.
Global   : product-catalog, pricing config, docs, analytics
           agregat teranonimkan (verifikasi anonimasi oleh
           tim data - syarat eksplisit).
 
## Pola terpilih: Cell-based terbatas
Cell EU : identitas + order + payment gateway EU.
Global  : sisanya; komunikasi via event non-PII.
 
## Keputusan terkait
K1 Routing by tenant-home-region (flag permanen).
K2 Failover EU intra-region saja; DR cross-border dilarang
   tanpa exception legal tercatat.
K3 Backup EU -> storage di EU; retensi 35 hari.
K4 Fitur admin lintas cell: hanya via metadata anonim.
 
## Ukuran sukses
Audit internal Q1: nol temuan residency;
p95 API EU < 120 ms; biaya tambahan <= 18% total infra.

Bagian klasifikasi dengan pemilik keputusan (K1-K4) membuat dokumen ini layak jadi ADR pendamping — dan inilah artefak yang akan ditanya auditor maupun engineer baru enam bulan kemudian.

#Pitfall Umum Multi-Region & Residency

• Multi-region sebagai mainan resume-driven — kompleksitas n-region tanpa driver bisnis nyata adalah pajak permanen pada semua tim.
• Lupa clock skew dan ordering — begitu data bergerak lintas region, timestamp server tak lagi bisa dipercaya untuk ordering; pakai logical clocks atau hindari kebutuhannya.
• Konsistensi lintas cell diam-diam diasumsikan — fitur "lihat profil pengguna lain" lintas region memaksa replikasi PII; daftar fitur lintas-cell WAJIB ditinjau sebelum pola dipilih.
• Backup & analytics lupa ikut aturan — artefak turunan mewarisi residensi; audit mereka bersama data utama.
• Failover belum pernah dilatih — topologi multi-region yang tidak didrill adalah teori; jadwalkan game-day sebelum dipercaya.

#Penutup

Inti yang harus dibawa pulang:

• Klasifikasi data mendahului arsitektur; minimalkan permukaan data yang butuh pinning sebelum membangun apa pun.
• Empat pola — active-passive, front door, replicas, cell-based — naik biaya dan kemampuan residensinya; residency keras realistisnya cell-based.
• Selalu saring dengan pertanyaan: apakah regulasi benar mewajibkan, dan apakah latensi nyata masalah bisnis?
• Artefak turunan (backup, log, analytics) mewarisi residensi data asalnya.

Di episode 21 kita masuk Fase 5 dengan membahas AI systems leadership — cara staff engineer memimpin inisiatif AI/LLM lintas tim: arsitektur RAG dan agent, eval harness yang menjadikan kualitas terukur, governance biaya dan safety, serta rencana inisiatif AI yang realistis. Sampai jumpa di episode 21!