Active-Passive vs Active-Active Multi-Region: Trade-off Nyata untuk Aplikasi SaaS

Active-passive vs active-active multi-region bukan sekadar pilihan antara availability rendah dan tinggi. Active-passive biasanya lebih sederhana, murah, dan aman untuk data yang sulit direplikasi, tetapi failover membutuhkan waktu dan kapasitas cadangan. Active-active dapat mengurangi latensi pengguna global dan mempertahankan layanan saat satu region gagal, tetapi memperbesar risiko konflik data, split-brain, dan kegagalan operasional.

Untuk kebanyakan SaaS yang baru berevolusi dari single-region, active-passive dengan region cadangan yang teruji adalah titik awal paling rasional. Active-active layak dipilih jika kebutuhan bisnis memang menuntut latensi regional rendah, RTO sangat pendek, serta kemampuan tetap menerima traffic dan penulisan ketika satu region gagal—dan tim sanggup mengelola model konsistensi datanya.

Definisi dan contoh topologi

Active-passive

Pada active-passive, satu region melayani traffic produksi. Region lain disiapkan sebagai cadangan, menerima replikasi data, tetapi tidak melayani traffic utama. Region cadangan dapat berupa:

• Cold standby: hanya data atau artefak cadangan yang tersedia. Infrastruktur dibuat atau dipulihkan setelah insiden.
• Warm standby: layanan inti berjalan dengan kapasitas terbatas dan dapat dinaikkan ketika failover.
• Hot standby: hampir seluruh stack berjalan dan siap menerima traffic, tetapi operasi tulis tetap diarahkan ke region utama.

Pengguna
   |
Global DNS / traffic manager
   |
Region A — ACTIVE
  App + worker + database writer
             |
             | replikasi asinkron atau sinkron
             v
Region B — PASSIVE
  App standby + database replica + salinan objek

Active-passive tidak selalu berarti region kedua benar-benar tidak digunakan. Region pasif dapat melayani pemeriksaan kesehatan, pengujian sintetis, atau pekerjaan nonkritis selama aktivitas tersebut tidak mengganggu kesiapan failover.

Active-active

Pada active-active, dua atau lebih region melayani traffic produksi secara bersamaan. Lapisan aplikasi stateless relatif mudah dibuat aktif di banyak region. Bagian sulitnya adalah menentukan bagaimana database, queue, cache, object storage, dan pekerjaan latar belakang berperilaku ketika penulisan terjadi di beberapa lokasi.

                  +-- Region A: app + worker + data endpoint
Pengguna -- Global traffic manager
                  +-- Region B: app + worker + data endpoint

Data dapat menggunakan salah satu pola:
1. single global writer
2. writer per tenant atau per shard
3. multi-writer dengan resolusi konflik
4. data lokal per region dengan replikasi terkontrol

Arsitektur aplikasi dapat terlihat active-active sementara database masih menggunakan single writer. Pola ini mengurangi gangguan pada lapisan komputasi, tetapi request tulis dari region jauh tetap membayar latensi lintas region dan database writer tetap menjadi komponen failover penting.

Perbandingan trade-off teknis dan operasional

Availability, RTO, dan RPO adalah hasil desain, bukan label

RTO adalah target waktu pemulihan layanan. RPO adalah batas kehilangan data yang dapat diterima, biasanya dinyatakan sebagai jarak waktu dari kejadian terakhir yang berhasil dipertahankan. Menyebut sistem active-active tidak membuktikan RTO atau RPO tertentu.

RTO nyata mencakup seluruh jalur pemulihan:

RTO aktual = deteksi + keputusan + isolasi + promosi data
           + pengalihan traffic + pemanasan kapasitas + validasi

RPO ditentukan oleh commit dan replikasi. Replikasi asinkron umumnya memiliki peluang kehilangan write yang belum sampai ke region cadangan. Replikasi sinkron lintas region dapat memperkecil RPO, tetapi commit harus menunggu komunikasi antarlokasi sehingga latensi dan kemungkinan timeout meningkat.

Jangan menetapkan RTO dan RPO hanya untuk database. Autentikasi, object storage, queue, secret, DNS, sertifikat, dan konfigurasi juga dapat menghalangi pemulihan.

Replikasi, konsistensi, dan konflik penulisan

Pertanyaan utama active-active bukan “apakah database mendukung multi-region”, melainkan “operasi bisnis mana yang boleh terjadi secara bersamaan dan bagaimana konflik diselesaikan”. Contohnya, profil pengguna mungkin dapat memakai aturan versi terakhir, tetapi pembayaran, kuota, nomor invoice, dan pengurangan stok membutuhkan kontrol lebih kuat.

Pola yang umum digunakan antara lain:

• Single writer global: semua write diarahkan ke satu region. Sederhana, tetapi latency write dan failover writer tetap menjadi masalah.
• Home region per tenant: setiap tenant memiliki region penulis yang jelas. Region lain dapat melayani read atau meneruskan write ke home region.
• Sharding geografis: kepemilikan data dibagi berdasarkan tenant atau domain. Perpindahan kepemilikan harus menggunakan prosedur eksplisit.
• Multi-writer: beberapa region menulis data yang sama. Cocok hanya jika database dan model domain memiliki aturan konflik yang benar.
• Eventual consistency: perubahan menyebar kemudian. Aplikasi harus mampu menghadapi stale read, event berulang, dan urutan event yang berbeda.

Gunakan idempotency key untuk operasi yang mungkin dikirim ulang akibat timeout atau failover. Key perlu disimpan bersama hasil operasi pada boundary yang memiliki jaminan transaksional. Memeriksa key di cache lalu menulis database secara terpisah masih membuka race condition.

BEGIN;

INSERT INTO idempotency_keys (tenant_id, operation_key, status)
VALUES (:tenant, :key, 'started')
ON CONFLICT DO NOTHING;

-- Jika key sudah memiliki hasil final, kembalikan hasil tersebut.
-- Jika request ini memiliki hak memproses, lakukan perubahan bisnis.

UPDATE idempotency_keys
SET status = 'completed', response_ref = :result
WHERE tenant_id = :tenant AND operation_key = :key;

COMMIT;

Contoh tersebut bersifat pola konseptual; detail locking dan sintaks upsert perlu disesuaikan dengan database. Untuk pesan asynchronous, consumer juga harus idempotent karena failover broker atau retry dapat mengirim event lebih dari sekali.

Split-brain dan fencing

Split-brain terjadi ketika dua region sama-sama menganggap dirinya berhak menerima write, misalnya karena koneksi antaregion putus tetapi keduanya masih hidup. DNS saja tidak cukup mencegahnya: resolver dapat menyimpan alamat lama, koneksi persisten tetap terbuka, dan layanan internal dapat melewati traffic manager.

Failover writer membutuhkan fencing, yaitu mekanisme yang memastikan writer lama tidak lagi memiliki hak menulis sebelum writer baru dipromosikan. Implementasinya dapat berupa lease dengan quorum, epoch atau generation number, pencabutan kredensial, atau kontrol promosi bawaan sistem database. Prinsipnya, setiap write dari generation lama harus ditolak.

Failover traffic bukan sekadar mengganti DNS

DNS failover mudah dioperasikan, tetapi TTL bukan jaminan bahwa semua client akan berpindah tepat waktu. Global load balancer atau anycast dapat bereaksi lebih cepat untuk koneksi baru, tetapi tidak otomatis memulihkan koneksi lama atau memperbaiki database.

Urutan failover active-passive yang aman biasanya mencakup:

1. Konfirmasi bahwa insiden bukan sekadar kegagalan monitoring.
2. Isolasi region lama dan hentikan worker, scheduler, serta writer yang dapat menghasilkan perubahan.
3. Ukur posisi replikasi dan tentukan risiko kehilangan data.
4. Promosikan database atau endpoint data di region cadangan.
5. Aktifkan scheduler tunggal, consumer queue, dan integrasi keluar secara terkendali.
6. Alihkan traffic secara bertahap jika mekanisme routing memungkinkan.
7. Jalankan smoke test untuk login, read, write, upload, dan alur bisnis kritis.
8. Pantau error rate, latency, backlog, kapasitas, dan perbedaan data.

Failback sering lebih berisiko daripada failover. Region lama mungkin membawa data usang. Jangan langsung mengarahkannya kembali sebagai writer; bangun ulang atau sinkronkan dari sumber kebenaran yang baru, validasi, lalu lakukan perpindahan terencana.

Skenario kegagalan region yang realistis

Misalkan sebuah SaaS memiliki region A sebagai primary dan region B sebagai warm standby. Database direplikasi secara asinkron, sedangkan artefak aplikasi dan konfigurasi dikelola dengan infrastructure as code.

Skenario 1: region A benar-benar tidak dapat diakses

Monitoring dari beberapa lokasi mendeteksi endpoint dan dependensi regional gagal. Setelah batas keputusan terlewati, tim mempromosikan replica di B, meningkatkan kapasitas aplikasi, mengaktifkan worker, lalu mengalihkan traffic. RTO dipengaruhi oleh waktu deteksi, promosi, dan scale-up. RPO bergantung pada replication lag sesaat sebelum A hilang.

Skenario 2: hanya koneksi A–B yang putus

Kedua region masih melayani sistem lokal, tetapi tidak dapat saling melihat. Promosi otomatis tanpa quorum dapat membuat dua writer. Respons yang aman bergantung pada kebijakan: pertahankan A sebagai writer, hentikan write pada sisi yang kehilangan lease, atau turunkan layanan menjadi read-only. Availability dapat sengaja dikurangi untuk menjaga konsistensi transaksi kritis.

Skenario 3: database sehat, tetapi identity provider atau queue regional gagal

Health check HTTP sederhana mungkin masih hijau walaupun pengguna tidak dapat login atau pekerjaan pembayaran berhenti. Karena itu, status region harus dibangun dari indikator per capability, bukan satu endpoint biner. Sistem dapat tetap menerima read sambil menonaktifkan operasi yang membutuhkan dependensi gagal.

Skenario 4: kegagalan logis direplikasi ke semua region

Penghapusan data tidak sengaja, migration rusak, atau kredensial aplikasi yang disalahgunakan dapat direplikasi dengan sempurna ke region lain. Multi-region bukan pengganti backup. Diperlukan backup terisolasi, point-in-time recovery jika tersedia, retention yang sesuai, dan pengujian restore.

Biaya dan kapasitas yang sering diremehkan

Perbandingan biaya harus memakai model komponen, bukan hanya jumlah mesin aplikasi. Estimasi bulanan dapat disusun sebagai berikut:

Total biaya multi-region =
  compute aplikasi dan worker
+ database primer, replica, dan backup
+ object storage dan replikasi
+ traffic manager, load balancer, NAT, dan alamat jaringan
+ data egress antaregion dan ke pengguna
+ log, metric, trace, serta retention
+ lisensi atau layanan keamanan
+ kapasitas cadangan
+ waktu engineering, on-call, drill, dan respons insiden

Data egress dapat tumbuh dari replikasi database, log terpusat, event bus lintas region, cache invalidation, backup, dan request yang masuk di satu region tetapi menulis ke region lain. Ukur volume byte per jalur, bukan hanya request per second.

Model kapasitas setelah kehilangan satu region

Dalam active-active dua region dengan pembagian traffic seimbang, masing-masing region tidak boleh direncanakan hanya untuk beban normalnya jika targetnya tetap beroperasi setelah satu region gagal. Region yang bertahan harus memiliki headroom, reservasi, atau jalur scale-out yang telah diuji.

Warm standby active-passive juga tidak gratis. Jika kapasitas cadangan terlalu kecil dan penyedia cloud sedang kekurangan kapasitas saat bencana luas, asumsi scale-up cepat dapat gagal. Untuk workload kritis, pertimbangkan kapasitas minimum yang selalu berjalan dan mekanisme reservasi yang sesuai dengan platform.

Observability, deployment, dan pengujian

Observability harus memiliki dimensi region

Metric agregat global dapat menyembunyikan kegagalan satu region. Dashboard dan alert setidaknya perlu memisahkan:

• traffic, error rate, dan latency per region serta per dependency;
• replication lag berdasarkan waktu dan posisi log jika tersedia;
• status writer, epoch, lease, atau kepemilikan shard;
• queue depth, umur pesan tertua, dan tingkat retry;
• hasil synthetic transaction dari luar setiap region;
• kapasitas CPU, memori, connection pool, disk, dan batas layanan;
• jumlah konflik, rekonsiliasi gagal, dan duplicate operation;
• versi aplikasi, schema, konfigurasi, serta feature flag per region.

Log dan trace perlu membawa region, tenant_id, request ID, dan operation atau idempotency key. Hindari mengirim seluruh telemetri hanya ke satu endpoint regional tanpa buffer atau jalur alternatif, karena observability justru dapat hilang saat paling dibutuhkan.

Deployment dan perubahan schema

Deployment multi-region memerlukan kompatibilitas lintas versi. Gunakan pola expand-and-contract untuk perubahan schema: tambahkan struktur baru yang kompatibel, deploy kode yang dapat membaca format lama dan baru, migrasikan data, lalu hapus struktur lama setelah seluruh region stabil.

Hindari kondisi ketika region A menjalankan producer dengan format event baru sementara consumer di B belum mengenalnya. Contract test, versioning event, dan rollout bertahap lebih penting daripada kecepatan deployment. Secrets, IAM, sertifikat, konfigurasi, dan feature flag juga harus tersedia secara konsisten tanpa menyalin hak akses berlebihan.

Pengujian yang benar-benar berguna

• Restore test: pulihkan backup ke lingkungan terisolasi dan validasi data, bukan hanya status job backup.
• Failover test: pindahkan traffic dan writer ke region cadangan menggunakan runbook yang sama dengan produksi.
• Dependency isolation: simulasi putusnya jaringan antaregion, bukan hanya mematikan instance aplikasi.
• Capacity test: buktikan region tersisa dapat menyerap traffic, worker, dan connection pool.
• Data reconciliation: bandingkan jumlah record, checksum tersegmentasi, ledger, atau invariant bisnis.
• Failback test: latih pembangunan ulang region lama dan pengembalian traffic tanpa membuat dua writer.

Tabel keputusan berdasarkan kebutuhan bisnis

Tahapan evolusi yang aman dari single-region

1. Perkuat single-region. Gunakan beberapa availability zone jika platform mendukung, hilangkan single point of failure, siapkan backup, dan uji restore.
2. Buat aplikasi dapat direproduksi. Gunakan infrastructure as code, artefak immutable, konfigurasi terversi, dan otomatisasi provisioning.
3. Pisahkan state dari compute. Hindari session lokal, file pada disk instance, dan scheduler yang dapat berjalan ganda. Gunakan penyimpanan state yang memiliki strategi replikasi jelas.
4. Bangun region cadangan. Mulai dari cold atau warm standby berdasarkan RTO. Replikasi database dan object storage, tetapi pertahankan satu writer.
5. Latih failover active-passive. Ukur setiap tahap, perbaiki runbook, dan kurangi langkah manual yang rawan salah.
6. Aktifkan read atau traffic aman di region kedua. Mulai dari endpoint stateless, konten cacheable, atau read yang toleran terhadap stale data.
7. Tentukan ownership write. Jika active-active diperlukan, gunakan home region per tenant atau shard sebelum mempertimbangkan multi-writer bebas.
8. Tambahkan multi-writer hanya untuk domain yang membutuhkannya. Dokumentasikan invariant, resolusi konflik, idempotensi, dan proses rekonsiliasi.

Evolusi bertahap memisahkan manfaat compute multi-region dari kompleksitas data multi-region. Tidak semua komponen harus berubah menjadi active-active secara bersamaan.

Kapan multi-region justru menambah risiko

Multi-region dapat menurunkan reliability jika kompleksitasnya melampaui kemampuan organisasi. Tanda-tandanya meliputi:

• backup belum pernah direstore, tetapi tim sudah merancang multi-writer;
• tidak ada target RTO/RPO yang disetujui bisnis;
• failover otomatis mengandalkan satu health check yang rentan false positive;
• tidak tersedia fencing untuk writer lama;
• aplikasi mengasumsikan read selalu langsung melihat write terakhir;
• migration dan event tidak kompatibel lintas versi;
• kapasitas region tersisa tidak pernah diuji;
• on-call tidak dapat melihat replication lag atau lokasi writer;
• region menggunakan dependency global yang sama sehingga kegagalan tetap berkorelasi;
• biaya egress dan observability membuat tim mengurangi retention atau monitoring kritis.

Menambah region juga tidak menyelesaikan kegagalan global pada kode, kredensial, control plane, provider identitas, atau konfigurasi yang sama. Isolasi failure domain harus dianalisis dari ujung ke ujung.

Checklist keputusan dan validasi melalui DR drill

Checklist sebelum memilih arsitektur

• Apakah RTO dan RPO ditentukan per capability bisnis, bukan hanya per layanan?
• Berapa nilai kerugian downtime dibandingkan biaya multi-region?
• Apakah pengguna membutuhkan latency regional rendah untuk read, write, atau keduanya?
• Data mana yang boleh eventual consistent dan mana yang membutuhkan konsistensi kuat?
• Bisakah data dipartisi berdasarkan tenant, region, atau domain?
• Bagaimana mencegah dua writer setelah network partition?
• Bagaimana queue, scheduler, webhook, email, dan pembayaran menghindari eksekusi ganda?
• Apakah backup terisolasi dan restore telah diuji?
• Apakah region cadangan memiliki data, secrets, sertifikat, konfigurasi, dan kapasitas yang cukup?
• Berapa biaya compute, database, storage, egress, telemetry, lisensi, dan tenaga operasional?
• Apakah tim mampu melakukan rekonsiliasi dan failback?
• Apakah persyaratan residensi data mencakup backup, log, dan akses support?

Rancangan disaster recovery drill

DR drill harus memiliki hipotesis, batas keamanan, dan kriteria lulus. Contoh tujuan: “Jika region utama tidak dapat diakses, layanan login, read, dan pembuatan transaksi pulih di region cadangan dalam target RTO, sedangkan kehilangan data tidak melebihi RPO.”

1. Catat topology, owner keputusan, jalur eskalasi, dan kondisi pembatalan.
2. Ambil baseline traffic, replication lag, backlog, kapasitas, serta invariant data.
3. Injeksikan kegagalan yang spesifik, misalnya memutus routing ke region atau memblokir koneksi replikasi.
4. Jalankan runbook tanpa jalan pintas yang tidak tersedia saat insiden nyata.
5. Ukur waktu deteksi, keputusan, fencing, promosi, rerouting, pemanasan, dan validasi secara terpisah.
6. Jalankan transaksi sintetis dan verifikasi side effect eksternal tidak terduplikasi.
7. Rekonsiliasi data serta catat transaksi yang hilang, tertunda, atau berkonflik.
8. Lakukan failback atau pembangunan ulang region lama.
9. Buat daftar perbaikan dengan owner dan tenggat, lalu ulangi drill setelah perubahan selesai.

Mulailah dari drill terjadwal dengan blast radius terbatas, lalu tingkatkan menuju latihan produksi yang realistis. Otomatisasi membantu konsistensi, tetapi keputusan berisiko seperti promosi writer tetap memerlukan guardrail, audit trail, dan mekanisme penghentian.

Kesimpulannya: pilih active-passive ketika tujuan utama adalah disaster recovery yang dapat dipahami dan diuji dengan kompleksitas terkendali. Pilih active-active jika kebutuhan latency, availability, atau operasi independen per region dapat membenarkan biaya dan kompleksitas konsistensi data. Ukuran keberhasilan bukan jumlah region, melainkan apakah sistem memenuhi RTO/RPO yang telah dibuktikan melalui DR drill.