High Availability: Kenapa Sistem Harus Tetap Hidup Meski Ada yang Mati

Apa itu High Availability?

High Availability (HA) itu konsep di mana sistem didesain supaya tetap bisa diakses dan berfungsi meskipun ada komponen yang gagal.

Bayangin ATM bank. Kamu harap bisa narik uang kapan aja — jam 2 pagi, hari libur, hujan badai. Kalau ATM-nya mati, kamu kesel. Kalau semua ATM satu bank mati barengan, itu bencana.

Sistem yang highly available didesain supaya hal kayak gitu ga terjadi. Atau kalau terjadi, dampaknya minimal dan pemulihannya cepat.

Kenapa High Availability Penting?

Uang

Downtime itu mahal. Beneran mahal.

Bayangin e-commerce besar yang down 1 jam pas flash sale. Berapa transaksi hilang? Berapa revenue yang ga masuk? Belum lagi biaya recover, kompensasi, dan customer yang kabur ke kompetitor.

Menurut Gartner, rata-rata biaya downtime itu sekitar Rp90 juta per menit. Untuk perusahaan besar bisa miliaran rupiah per jam.

Reputasi

User itu ga sabar. Kalau app kamu down, mereka ga mikir "oh mungkin lagi maintenance." Mereka mikir "app ini jelek" dan pindah ke alternatif.

Downtime berulang = trust hilang = user hilang. Dan dapetin user baru itu jauh lebih mahal dari retain yang ada.

Compliance

Beberapa industri punya regulasi soal uptime:

• Perbankan: sistem pembayaran harus available hampir 24/7
• Healthcare: sistem rekam medis harus bisa diakses kapan aja
• Telco: jaringan komunikasi punya SLA ketat

Ga comply? Denda. Atau lebih parah, lisensi dicabut.

Mengukur Availability: The Nines

Availability diukur dalam persentase uptime per tahun. Kita sebutnya "the nines".

Perhatiin bedanya. Dari 99% ke 99.99% itu beda dari 3.65 hari downtime ke 52 menit per tahun.

Setiap "nine" tambahan itu exponentially lebih susah dan lebih mahal buat dicapai.

Kebanyakan sistem production target 99.9% sampai 99.99%. Lima nines itu level NASA atau sistem trading bursa saham.

Rumusnya

Availability = (Total Time - Downtime) / Total Time × 100%

Atau lebih praktis: cek SLA (Service Level Agreement) dari cloud provider kamu. AWS EC2 SLA-nya 99.99%. GCP Compute Engine juga 99.99%.

Tapi ingat: SLA provider ≠ SLA aplikasi kamu. Provider bisa 99.99%, tapi kalau arsitektur kamu jelek, availability aplikasi kamu tetep bisa 95%.

Single Point of Failure (SPOF)

Ini musuh utama High Availability.

Single Point of Failure = satu komponen yang kalau mati, seluruh sistem ikut mati.

Contoh SPOF

graph LR
    User --> Server[Satu Server] --> DB[Satu Database]

Server mati? App down.
Database mati? App down.
Network ke server bermasalah? App down.

Setiap kotak di diagram itu SPOF. Satu aja gagal, semuanya tumbang.

Eliminasi SPOF

Prinsipnya simpel: jangan pernah bergantung pada satu komponen tunggal.

graph LR
    User --> LB[Load Balancer]
    LB --> S1[Server 1]
    LB --> S2[Server 2]
    LB --> S3[Server 3]
    S1 --> DB1[(DB Primary)]
    S2 --> DB1
    S3 --> DB1
    DB1 --> DB2[(DB Replica)]

Sekarang:

• Server 1 mati? Load balancer redirect ke Server 2 dan 3
• Database primary mati? Replica di-promote jadi primary

Ga ada satu titik kegagalan yang bisa tumbangin seluruh sistem.

Strategi High Availability

1. Redundancy

Redundancy itu punya cadangan untuk setiap komponen kritis.

Active-Active

Semua instance aktif dan melayani traffic secara bersamaan.

graph LR
    User --> LB[Load Balancer]
    LB --> S1["Server 1 ✅ aktif"]
    LB --> S2["Server 2 ✅ aktif"]
    LB --> S3["Server 3 ✅ aktif"]

• Traffic dibagi rata (atau sesuai kapasitas) ke semua server
• Satu server mati? Yang lain ambil alih porsi traffic-nya
• Kelebihan: resource terpakai efisien, capacity tinggi
• Kekurangan: semua server harus di-maintain, state synchronization bisa complex

Active-Passive (Standby)

Ada satu (atau lebih) instance yang standby, cuma aktif kalau yang primary mati.

graph LR
    User --> S1["Server 1 ✅ aktif"]
    S1 -.->|failover| S2["Server 2 💤 standby"]

• Dalam kondisi normal, cuma Server 1 yang kerja
• Server 1 mati → Server 2 take over (failover)
• Kelebihan: lebih simpel, ga perlu sync real-time
• Kekurangan: Server 2 idle = buang resource, failover ga instan (ada delay)

Mana yang dipilih?

Tergantung situasi:

• Butuh zero downtime dan throughput tinggi? → Active-Active
• Budget terbatas, bisa toleransi beberapa detik downtime? → Active-Passive
• Database? Biasanya Active-Passive (primary-replica) karena write consistency

2. Load Balancing

Load balancer itu traffic cop yang bagi-bagi request ke server yang available.

Algoritma Load Balancing

• Round Robin: giliran satu-satu. Server 1 → Server 2 → Server 3 → Server 1 → ...
• Least Connections: kirim ke server yang lagi paling sedikit handle request
• Weighted: kasih bobot. Server yang lebih kuat dapet porsi lebih besar
• IP Hash: request dari IP yang sama selalu ke server yang sama (berguna kalau butuh session affinity)

Health Check

Load balancer secara berkala cek: "server ini masih hidup ga?"

sequenceDiagram
    participant LB as Load Balancer
    participant S1 as Server 1
    participant S2 as Server 2
    participant S3 as Server 3

    LB->>S1: ping
    S1-->>LB: 200 OK ✅ healthy
    LB->>S2: ping
    Note right of S2: timeout ❌ unhealthy
    LB->>S3: ping
    S3-->>LB: 200 OK ✅ healthy

Server yang ga response dihapus dari pool. Kalau udah sehat lagi, ditambahin balik. Ini terjadi otomatis.

Layer 4 vs Layer 7

• Layer 4 (Transport): route berdasarkan IP dan port. Cepat, tapi ga bisa lihat isi request
• Layer 7 (Application): route berdasarkan content — URL path, header, cookie. Lebih fleksibel, bisa bikin aturan kayak "request ke /api ke backend pool, request ke / ke frontend pool"

3. Database Replication

Database itu biasanya komponen paling kritis dan paling susah di-HA-kan.

Primary-Replica (Master-Slave)

graph LR
    W[Write] --> P[(Primary DB)]
    R[Read] --> R1[(Replica DB 1)]
    R --> R2[(Replica DB 2)]
    P -.->|replicate| R1
    P -.->|replicate| R2

• Semua write ke primary
• Primary replikasi data ke replica
• Read bisa di-spread ke replica → mengurangi beban primary
• Primary mati → salah satu replica di-promote jadi primary baru

Synchronous vs Asynchronous Replication

Synchronous: primary tunggu sampai replica confirm sudah terima data, baru bilang "write sukses" ke client.

sequenceDiagram
    participant C as Client
    participant P as Primary DB
    participant R as Replica DB

    C->>P: Write
    P->>R: Replicate
    R-->>P: Confirm
    P-->>C: Write sukses

• Pro: data pasti konsisten antara primary dan replica
• Con: lebih lambat, kalau replica down write bisa stuck

Asynchronous: primary langsung bilang "write sukses" tanpa nunggu replica.

sequenceDiagram
    participant C as Client
    participant P as Primary DB
    participant R as Replica DB

    C->>P: Write
    P-->>C: Write sukses
    P-)R: Replicate (background)

• Pro: lebih cepat, replica down ga ngaruh ke write performance
• Con: kalau primary mati sebelum data sampai replica, data bisa hilang. Ada replication lag

Kebanyakan sistem pakai async replication dan terima risiko kehilangan beberapa detik data terakhir kalau worst case terjadi. Trade-off yang acceptable buat kebanyakan use case.

4. Failover

Failover itu proses perpindahan otomatis dari komponen yang gagal ke cadangannya.

Kriteria Failover

Kapan failover harus terjadi?

• Server ga response health check selama X detik
• Error rate melonjak di atas threshold
• Resource usage (CPU/memory) melampaui batas
• Manual trigger oleh operator

Failover Time

Waktu dari komponen gagal sampai cadangan take over. Ini salah satu metrik HA yang paling penting.

• Hot standby: cadangan udah running dan siap. Failover dalam hitungan detik
• Warm standby: cadangan running tapi ga fully loaded. Failover dalam hitungan menit
• Cold standby: cadangan mati, perlu dinyalain dan di-setup. Failover dalam hitungan menit sampai jam

Makin cepat failover, makin mahal. Lagi-lagi trade-off.

Split-Brain Problem

Ini masalah klasik di sistem HA.

Bayangin: dua server, keduanya pikir yang lain mati. Keduanya ambil alih jadi primary.

Server 1: "Server 2 ga response, gue jadi primary!"
Server 2: "Server 1 ga response, gue jadi primary!"

Sekarang ada dua primary yang terima write. Data diverge. Kacau.

Solusinya:

• Quorum: butuh mayoritas vote dari cluster sebelum bisa jadi primary. Minimal 3 node, butuh 2 setuju
• Fencing: kalau diputusin jadi bukan primary, server di-"fence" (dimatikan paksa) supaya ga interfere
• Shared storage lock: pakai lock di storage bersama buat tentukan siapa yang jadi primary

5. Geographic Redundancy

Semua strategi di atas percuma kalau semua server ada di satu gedung data center dan gedung itu kebakaran.

Multi-AZ (Availability Zone)

Cloud provider kayak AWS, GCP, Azure punya availability zones — data center yang terpisah secara fisik tapi masih dalam satu region.

graph TB
    subgraph Region["ap-southeast-1 (Singapore)"]
        subgraph AZ1["AZ-1 (Data Center A)"]
            S1[Server 1]
            R1[(DB Replica 1)]
        end
        subgraph AZ2["AZ-2 (Data Center B)"]
            S2[Server 2]
            R2[(DB Replica 2)]
        end
        subgraph AZ3["AZ-3 (Data Center C)"]
            S3[Server 3]
            P[(DB Primary)]
        end
    end
    P -.-> R1
    P -.-> R2

Satu AZ mati (listrik, banjir, kebakaran)? AZ lain masih jalan.

Multi-Region

Lebih extreme: deploy di beberapa region yang berbeda-beda (misal Singapore DAN Tokyo).

• Pro: protect dari bencana yang affect satu region, latency lebih rendah buat user di region lain
• Con: data replication lintas region itu complex dan ada latency, cost jauh lebih tinggi

Kebanyakan perusahaan cukup dengan Multi-AZ. Multi-Region buat yang beneran butuh global reach atau regulatory compliance.

Availability vs Consistency: CAP Theorem

Ini penting dipahami. Ga bisa dapet semuanya.

CAP Theorem bilang: dalam distributed system, kamu cuma bisa dapet dua dari tiga:

• Consistency: semua node lihat data yang sama pada waktu yang sama
• Availability: setiap request dapet response (ga error)
• Partition Tolerance: sistem tetep jalan meskipun ada network partition (komunikasi antar node terputus)

Dalam real world, network partition itu pasti terjadi. Jadi pilihan yang realistis:

• CP (Consistency + Partition Tolerance): kalau ada partition, sistem menolak request daripada kasih data yang ga konsisten. Contoh: database tradisional (PostgreSQL cluster)
• AP (Availability + Partition Tolerance): kalau ada partition, sistem tetep response tapi data mungkin ga konsisten antar node. Contoh: Cassandra, DynamoDB

Buat High Availability, kebanyakan kita condong ke AP — lebih baik kasih data yang mungkin agak stale daripada error 500.

Tapi ini tergantung konteks:

• E-commerce catalog? AP boleh. Data produk stale beberapa detik ga masalah
• Transfer uang? CP wajib. Ga boleh ada inconsistency soal saldo

Monitoring dan Alerting

HA bukan cuma soal arsitektur. Kamu harus tahu kapan ada masalah, idealnya sebelum user tahu.

Metrics yang Harus Dipantau

• Uptime/Downtime: berapa lama sistem available. Ini metrik paling dasar
• Response Time (Latency): kalau tiba-tiba naik drastis, ada yang ga beres
• Error Rate: persentase request yang error (4xx, 5xx)
• Throughput: berapa request per detik yang bisa di-handle. Drop tiba-tiba = masalah
• Resource Usage: CPU, memory, disk, network. Saturated resource = potensi down

Alerting

Monitor tanpa alert itu kayak CCTV tanpa security guard. Ada rekaman, tapi ga ada yang bertindak.

Setup alert untuk:

• Availability di bawah threshold (misal < 99.9%)
• Latency melonjak di atas P99 threshold
• Error rate di atas X%
• Failover terjadi (supaya tim tahu ada komponen yang gagal)
• Resource usage mendekati kapasitas

Tools yang biasa dipake: Prometheus + Grafana, Datadog, New Relic, CloudWatch.

Common Mistakes

1. HA tanpa testing

Punya arsitektur HA tapi ga pernah test failover? Sama aja bohong.

Yang terjadi biasanya: diluar skenario yang di-plan, failover gagal juga. Atau: backup database yang ternyata corrupt dan ga pernah di-verify.

Test failover secara berkala. Kill server, cabut koneksi database, simulate network partition. Pastiin sistem beneran bisa recover.

2. Ignore dependent services

Sistem kamu HA, tapi nge-depend ke third-party API yang single server? Congrats, kamu cuma se-available provider terlemah kamu.

Availability sistem = A(server) × A(database) × A(cache) × A(third-party)
99.99% × 99.99% × 99.99% × 99% = ~99.97%

Satu komponen 99% ngejatuhkan availability keseluruhan. Chain is as strong as its weakest link.

3. Overspending on nines

Dari 99.9% ke 99.99% itu bisa nambah cost 10x lipat. Tanyain dulu: bisnis beneran butuh?

Blog personal? 99% udah lebih dari cukup.
Internal tool? 99.9% reasonable.
Payment processing? 99.99% minimum.
Air traffic control? Five nines or bust.

Match availability target sama business requirement, bukan ego engineering.

Ringkasan

Kesimpulan

High Availability bukan fitur yang ditambahin di akhir. Ini harus jadi bagian dari desain sejak awal.

Yang perlu diingat:

1. Identifikasi SPOF dan eliminasi satu per satu
2. Redundancy di setiap layer: compute, database, network
3. Failover harus otomatis dan harus di-test secara berkala
4. Monitor everything — ga bisa fix apa yang ga bisa dilihat
5. Sesuaikan target availability sama kebutuhan bisnis. Ga semua harus five nines
6. Terima trade-off — lebih available biasanya berarti lebih mahal dan lebih complex

Ga ada sistem yang 100% available. Yang ada adalah sistem yang didesain untuk recover secepat mungkin ketika kegagalan terjadi.

Karena pertanyaannya bukan "apakah akan gagal?" tapi "kapan gagal, dan seberapa cepat bisa pulih?"