Sistem Terdistribusi Tidak Rusak — Mereka Menurun Perlahan

Kita sering membayangkan kegagalan sistem sebagai sesuatu yang dramatis.
Satu tombol mati. Layar gelap. Sistem “down”.

Namun di dunia sistem terdistribusi, itu hampir tidak pernah terjadi.

Yang terjadi adalah penurunan bertahap.

Request masih masuk, tapi lebih lambat.
Beberapa fitur berhenti bekerja.
Data terasa tidak sinkron.
Error muncul—namun hanya untuk sebagian pengguna.

Dan justru di situlah bahayanya.

Karena sistem yang menurun terlihat masih hidup.

Kegagalan Total Itu Jarang. Kegagalan Parsial Itu Normal.

Dalam sistem terdistribusi:

• Jaringan tidak selalu stabil
• Service bisa restart kapan saja
• Database melambat di jam sibuk
• Cache bisa menyajikan data basi

Sistem tidak berhenti.
Ia pincang.

Kegagalan parsial bukan anomali—ia adalah kondisi normal.

Jika arsitekturmu hanya mengenal dua keadaan: hidup atau mati,
maka model mentalmu sudah keliru sejak awal.

Degradasi Bukan Kebetulan, Tapi Konsekuensi Desain

Ketika sistem menurun dengan buruk, kita menyebutnya “bug” atau “incident”.

Padahal degradasi bukan sesuatu yang acak.

Ia adalah hasil langsung dari keputusan desain:

• Ketergantungan sinkron yang berlebihan
• Tidak adanya timeout
• Retry tanpa batas
• Tidak ada fallback
• Asumsi bahwa dependency selalu tersedia

Sistem tidak tiba-tiba rusak.
Ia hanya berperilaku sesuai desainnya.

Blackout Mudah. Brownout Itu Sulit.

Mendesain untuk kegagalan total itu mudah:

“Jika database mati, tampilkan error.”

Yang sulit adalah mendesain untuk kondisi abu-abu:

• Apa yang tetap bisa berjalan saat database lambat?
• Fitur mana yang bisa dimatikan sementara?
• Data mana yang boleh basi tapi masih berguna?

Sistem yang matang tidak mengejar uptime sempurna.
Ia mengejar perilaku yang masih bisa diterima saat stres.

Graceful Degradation Itu Keputusan Produk

Sering kali degradasi dianggap urusan teknis.

Padahal ini adalah keputusan produk.

Menentukan:

• fitur mana yang krusial,
• mana yang bisa ditunda,
• mana yang boleh hilang sementara,

harus diputuskan sebelum production memaksanya.

Latency, konsistensi, dan kelengkapan data adalah kompromi.
Dan kompromi itu harus disadari, bukan terjadi secara tidak sengaja.

Metrik Bisa Menipu

“Uptime 99,9%” terdengar meyakinkan.

Tapi degradasi bersembunyi di detail:

• Latensi P99
• Gangguan regional
• User tertentu yang selalu gagal
• Job background yang diam-diam mati

Sistem terdistribusi jarang berteriak.
Ia berbisik.

Jika kamu hanya memantau status “up/down”,
kamu akan terlambat menyadari bahwa sistemmu sedang sekarat.

Menerima Degradasi Mengubah Cara Kita Mendesain

Ketika kita menerima bahwa degradasi itu normal:

• Timeout menjadi kewajiban
• Fallback menjadi fitur utama
• Feature flag menjadi katup pengaman
• Load shedding direncanakan sejak awal
• Observability fokus pada perilaku, bukan sekadar error

Tujuan kita bukan lagi “tidak pernah gagal”.

Tujuan kita adalah:
gagal dengan cara yang masih bisa ditoleransi pengguna.

Pertanyaan yang Sebenarnya

Pertanyaan pentingnya bukan:

“Apakah sistem ini bisa gagal?”

Ia pasti gagal.

Pertanyaan yang benar adalah:

“Bagaimana sistem ini berperilaku saat gagal?”

Karena dalam sistem terdistribusi,
kegagalan hanyalah momen.
Degradasi adalah kepribadian sistem.