Arsitektur Active-Active Multi-Region: Trade-off Biaya Egress & RPO

Menjalankan sistem multi-region sering dianggap sebagai standar emas ketersediaan tinggi (high availability). Namun, implementasi arsitektur Active-Active memperkenalkan kompleksitas sistem terdistribusi yang signifikan. Pilihan antara Active-Active dan Active-Passive bukan sekadar keputusan ketersediaan, melainkan kompromi langsung antara batas toleransi kehilangan data (Recovery Point Objective / RPO), waktu pemulihan (Recovery Time Objective / RTO), konsistensi data, dan biaya operasional jaringan.

Dinamika Biaya: Cross-Region Egress vs Idle Compute Standby

Dua arsitektur ini membebankan biaya finansial pada pos yang sangat berbeda di penyedia cloud (AWS, GCP, Azure):

• Active-Passive (Hot/Warm Standby): Biaya didominasi oleh idle compute. Node komputasi di region sekunder berjalan tanpa melayani lalu lintas produksi (atau hanya kapasitas minimum). Biaya transfer data jaringan (egress) relatif rendah karena hanya mencakup replikasi basis data asinkron satu arah dan sinkronisasi artifak sistem.
• Active-Active: Biaya komputasi lebih efisien karena utilisasi kapasitas terdistribusi di kedua region (misal: beban 50:50). Namun, biaya cross-region egress bandwidth meningkat secara eksponensial. Setiap transaksi yang memerlukan sinkronisasi status, replikasi dua arah, atau panggilan RPC lintas region antar-microservice dikenakan tarif transfer data inter-region.

Kalkulasi Kasus Nyata: Jika aplikasi Anda menghasilkan data write 500 GB per hari dengan replikasi multi-arah serta panggilan inter-region service mesh sebesar 2 TB per hari, total transfer egress mencapai ~75 TB per bulan. Di AWS, biaya transfer inter-region berkisar antara $0.01 hingga $0.02 per GB, menambahkan pengeluaran ribuan dolar murni untuk lalu lintas jaringan tanpa penambahan performa komputasi langsung.

Strategi Sinkronisasi dan Resolusi Write Conflict

Mendukung operasi write di beberapa region secara simultan membutuhkan strategi penanganan tabrakan data (write conflicts). Arsitektur data umumnya mengadopsi salah satu dari tiga pendekatan berikut:

1. Single-Leader Replication with Local Read Routing

Semua operasi write diarahkan ke satu region utama (Leader), sementara region sekunder hanya melayani pembacaan data (Follower). Pendekatan ini menghilangkan konflik write secara total.

• Trade-off: Write latency meningkat untuk pengguna yang jauh dari region Leader (terkena Round Trip Time / RTT lintas benua). Jika region Leader down, proses failover promosi Leader baru membutuhkan koordinasi ketat untuk menghindari data loss (RPO > 0).

2. Multi-Leader dengan Last-Write-Wins (LWW)

Setiap region menerima operasi write dan mereplikasi perubahan secara asinkron. Jika dua write memodifikasi record yang sama, write dengan timestamp lokal tertinggi diterima.

• Risiko: Jam fisik (physical wall-clock) pada server mengalami clock drift meski menggunakan NTP. LWW rentan terhadap silent data loss di mana pembaruan yang valid ditimpa oleh operasi yang terjadi lebih dulu hanya karena perbedaan beberapa milidetik pada jam server.

3. Conflict-Free Replicated Data Types (CRDT)

Menggunakan struktur data matematis yang menjamin status konvergen secara otomatis saat pembaruan digabungkan, tanpa memerlukan koordinasi terpusat.

// Implementasi sederhana LWW-Element-Set Dictionary untuk mendeteksi write conflict
type RecordState struct {
    Value     string
    Timestamp int64 // Epoch nanosecond
    IsDeleted bool
}

type LWWRegister struct {
    records map[string]RecordState
}

func (r *LWWRegister) Write(key string, value string, clientTime int64) {
    current, exists := r.records[key]
    // Update hanya jika timestamp baru lebih besar dari status lokal
    if !exists || clientTime > current.Timestamp {
        r.records[key] = RecordState{
            Value:     value,
            Timestamp: clientTime,
            IsDeleted: false,
        }
    }
}

CRDT sangat efektif untuk status yang bersifat komutatif (misalnya counter, set keranjang belanja, flag status), namun sulit diterapkan pada domain relasional kompleks dengan foreign key dan batasan keunikan (unique constraints).

Target RPO/RTO dan Realitas DNS Failover

Arsitektur Active-Active sering kali dipilih dengan asumsi mencapai RPO=0 dan RTO=0. Namun, implementasi routing jaringan membatasi target tersebut:

• TTL DNS dan Client-Side Caching: Pengalihan lalu lintas menggunakan DNS latency-based routing atau health checks memiliki kendala caching. Rekursor DNS ISP publik dan browser sering kali mengabaikan nilai TTL rendah (misal: 10 detik) dan tetap menyimpan cache IP lama selama 5 hingga 15 menit.
• RTO Riil: Walaupun infrastruktur backend siap melayani trafik seketika, RTO nyata bagi sebagian pengguna tetap berada di kisaran waktu kadaluwarsa cache DNS klien. Solusi yang lebih dapat diandalkan adalah menggunakan Anycast BGP routing (misalnya AWS Global Accelerator atau Cloudflare), yang mengalihkan rute traffic di level IP tanpa bergantung pada propagasi DNS.
• RPO pada Asynchronous Multi-Region: Dalam arsitektur Active-Active asinkron, jika satu region terisolasi secara katastropik, write yang masih mengantre di buffer replikasi lokal sebelum terkirim ke region lain akan hilang, menghasilkan RPO > 0.

Matriks Perbandingan Arsitektur Multi-Region

Analisis Dampak Maintainability dan Tim Engineering

Kompleksitas teknis Active-Active secara langsung membebani siklus operasional tim:

1. Migrasi Skema Database: Menjalankan DDL non-blocking pada Active-Passive dapat dilakukan bertahap (Follower dulu, lalu switch over). Pada Active-Active multi-leader, perubahan skema kolom atau constraint harus backward/forward compatible di seluruh region secara simultan untuk menghindari kegagalan serialisasi data replikasi.
2. Debugging dan Observability: Menelusuri jejak transaksi yang melibatkan distributed trace lintas batas geografis membutuhkan context propagation yang disiplin. Latensi jaringan non-deterministik antar-region sering menimbulkan race conditions yang sangat sulit direproduksi di lingkungan lokal (staging).

Panduan Pengambilan Keputusan

Gunakan kriteria berikut untuk menentukan pendekatan arsitektur yang rasional:

• Pilih Active-Passive jika: Batas toleransi RTO aplikasi berkisar antara 5 hingga 30 menit, data model memiliki integritas relasional ketat, dan anggaran operasional jaringan terbatas. Pola ini memberikan titik impas terbaik antara keandalan sistem dan biaya rekayasa.
• Pilih Active-Active Partitioned (Sharding Region) jika: Pengguna dapat dipartisi secara geografis (misal: user Eropa selalu menulis ke region Frankfurt, user Asia ke Singapura) tanpa butuh sinkronisasi data global langsung. Ini meminimalkan egress dan write conflict.
• Pilih Active-Active Multi-Leader penuh HANYA jika: Biaya downtime bisnis per menit melebihi biaya investasi infrastruktur dan engineering yang substansial, model data secara alami mendukung komutativitas (CRDT), dan dependensi eksternal mampu menangani konsistensi eventual (eventual consistency).