Pola Desain Sistem High Availability

TL;DR

• High availability adalah hasil dari keputusan tentang failure domain, data semantics, dan control path, bukan sekadar jumlah replika.
• Failover yang tidak diuji sering lebih berbahaya daripada komponen tunggal yang batasnya dipahami.
• Sistem yang benar-benar available tahu kapan harus degrade secara anggun, bukan selalu memaksakan failover penuh.

Pendahuluan

High availability mudah diucapkan tetapi sulit dicapai. Banyak sistem terlihat redundant di diagram, namun tetap gagal total saat dependency utama bermasalah atau proses failover tidak dirancang dengan baik. Redundansi instance hanyalah satu bagian kecil dari availability.

Availability yang nyata adalah kemampuan sistem mempertahankan tingkat layanan yang dapat diterima ketika host, zona, jaringan, dependency, atau manusia melakukan kesalahan.

Problem di Production

Di produksi, tim sering salah mengira availability sebagai proyek menambah replika. Padahal outage besar lebih sering datang dari dependency tunggal, quorum yang salah dipahami, atau jalur failover yang belum pernah diuji dalam kondisi realistis. Sistem terlihat redundant di diagram, tetapi tidak tahu bagaimana berperilaku saat state tertinggal atau jaringan antar-zona tidak stabil.

Mental Model

Pikirkan availability sebagai rangkaian keputusan tentang apa yang tetap harus hidup, apa yang boleh melambat, dan apa yang boleh dimatikan sementara. Jika semua komponen dianggap sama penting, tim akan membuat failover yang terlalu agresif atau terlalu lambat.

Konsep Utama

Redundansi tanpa independensi adalah redundansi yang lemah

Dua replika di failure domain yang sama bukan perlindungan yang berarti. Beberapa instance aplikasi yang semuanya bergantung pada satu database rapuh juga bukan sistem yang benar-benar highly available.

Stateful system membutuhkan pemahaman quorum

Untuk data dan koordinasi, quorum memberi jaminan konsistensi yang lebih baik, tetapi juga membawa konsekuensi latency dan sensitivitas terhadap partition. Tiga node lintas zona terlihat aman, tetapi perilakunya saat inter-zone network goyah harus dipahami.

Failover adalah masalah kontrol

Banyak outage bukan terjadi karena kurang replika, melainkan karena deteksi gagal yang buruk, threshold flapping, atau promosi secondary yang tidak siap menerima beban.

Dari sudut operasi

Secara operasional, desain availability yang sehat selalu memiliki definisi loss budget, runbook failover, dan metrik yang menunjukkan apakah sistem sedang benar-benar degraded atau hanya terlihat sibuk.

Arsitektur / Cara Kerja

Desain availability yang sehat biasanya mengevaluasi beberapa lapisan:

1. failure domain fisik atau logis
2. model replikasi state
3. health signal dan failover trigger
4. traffic steering
5. perilaku dependency saat degradasi
6. kesiapan operasional dan runbook

Active-passive cocok jika state sulit disinkronkan secara aman. Active-active cocok bila aplikasi dan data layer memang bisa mendukungnya. Tidak ada pola yang otomatis lebih baik; yang penting adalah kesesuaian dengan model data, latency budget, dan kemampuan operasional tim.

Decision point yang sering menentukan hasil

Lapisan control path seperti health check, traffic steering, leader election, dan dependency timeout sama pentingnya dengan data path. Dalam banyak insiden, control path yang salah lebih berbahaya daripada resource yang benar-benar mati.

Practical Implementation

Mulai dari kontrol paling sempit yang bisa langsung memberi nilai operasional. Fokusnya bukan membuat desain paling lengkap, tetapi membuat satu jalur implementasi yang dapat direview, diuji, dan dipulihkan.

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5
  failureThreshold: 3
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  periodSeconds: 10
  failureThreshold: 5

Studi Kasus / Masalah Nyata

Replika banyak tetapi dependency tetap tunggal

Service aplikasi memiliki banyak pod lintas zona, tetapi seluruh request harus melewati satu database utama atau satu shared cache yang tidak tahan gangguan. Dari luar tampak redundant, tetapi ketersediaan nyata tetap dikendalikan oleh dependency tunggal.

Failover otomatis mempromosikan target yang belum siap

Sistem mendeteksi primary tidak sehat lalu segera mengalihkan traffic ke secondary. Secondary memang hidup, tetapi datanya tertinggal dan koneksi pool belum siap. Hasilnya adalah outage yang berpindah bentuk, bukan pulih.

Ketahanan deploy lebih penting daripada replika tambahan

Banyak sistem gagal bukan karena host mati, tetapi karena deploy buruk, konfigurasi salah, atau feature flag yang tak terkendali. Availability design harus memasukkan kontrol perubahan sebagai bagian dari arsitektur.

Trade-offs

• Active-active memberi kapasitas dan ketahanan lebih baik, tetapi menuntut desain data yang jauh lebih disiplin.
• Quorum meningkatkan konsistensi, tetapi membawa latency dan sensitivitas terhadap partition.
• Graceful degradation sering lebih aman daripada failover total, tetapi memerlukan prioritas fitur yang jelas.

Best Practices

Tentukan failure scenario yang benar-benar ingin ditahan

Apakah targetnya tahan terhadap:

• host tunggal gagal
• satu availability zone hilang
• dependency tertentu melambat
• salah konfigurasi saat deploy
• network partition

Tanpa definisi ini, high availability hanya menjadi jargon.

Bangun graceful degradation

Tidak semua kegagalan harus diselesaikan dengan failover penuh. Sering kali lebih baik:

• menyajikan cache lama
• mematikan fitur non-kritis
• menunda pekerjaan asynchronous
• memakai circuit breaker

Uji failover secara realistis

Uji bukan hanya mematikan satu pod, tetapi juga kehilangan zona, dependency lambat, replikasi tertinggal, dan jalur observability yang terdegradasi.

Guardrail tambahan yang layak dipasang

• Active-active memberi kapasitas dan ketahanan lebih baik, tetapi menuntut desain data yang jauh lebih disiplin.
• Quorum meningkatkan konsistensi, tetapi membawa latency dan sensitivitas terhadap partition.
• Graceful degradation sering lebih aman daripada failover total, tetapi memerlukan prioritas fitur yang jelas.

Failure Modes

• Secondary dipromosikan saat state belum siap sehingga outage hanya berpindah bentuk.
• Health check terlalu dangkal dan mengarahkan traffic ke komponen yang hidup tetapi tidak siap melayani.
• Dependency tunggal seperti cache, queue, atau DB utama meniadakan manfaat replika aplikasi.

Kesalahan Umum

• menyamakan jumlah replika dengan availability
• mengabaikan dependency yang menjadi single point of failure
• memakai quorum tanpa memahami biaya latency dan partition
• menganggap failover sebagai runbook darurat, bukan control path yang diuji
• merancang ketahanan hardware tetapi mengabaikan bad deploy dan human error

Kesimpulan

High availability bukan hasil dari menggandakan komponen sebanyak mungkin. Ia lahir dari keputusan yang sadar tentang failure domain, quorum, failover, dependency behavior, dan kesiapan operasional. Sistem yang benar-benar available adalah sistem yang tetap masuk akal saat berada dalam kondisi terdegradasi.

Pada level senior engineer, tujuan utamanya bukan hanya membuat sistem berjalan, tetapi membuat pilihan desainnya cukup jelas untuk diaudit, diubah, dan dipulihkan saat kondisi produksi memburuk.

Pada level senior engineer, tujuan utamanya bukan hanya membuat sistem berjalan, tetapi membuat pilihan desainnya cukup jelas untuk diaudit, diubah, dan dipulihkan saat kondisi produksi memburuk.