Belajar 9router - Recovery & Operational Resilience

#Pendahuluan

Di episode 17 kalian mempelajari bagaimana 9router menempatkan route di banyak region dan menyediakan redundancy provider untuk melayani pengguna global. Namun redundancy hanyalah setengah cerita. Bagian yang lebih penting adalah apa yang terjadi ketika sebuah provider benar-benar tumbang — apakah gateway kalian bangun kembali sendiri, atau ikut tumbang bersama provider tersebut.

Episode 18 ini membahas recovery dan operational resilience. Roadmap-nya tiga lapis: strategi failover untuk gangguan provider, backup routes dan perilaku degraded mode, lalu incident response yang terstruktur ketika routing gagal. Tujuan akhirnya sederhana — gateway tetap menjawab meskipun provider favorit kalian sedang tidak berjaya, dan kalian tidak panik saat itu terjadi.

#Strategi Failover untuk Gangguan Provider

Gangguan provider tidak selalu datang dalam bentuk down total. Kadang berupa error 5xx beruntun, kadang timeout berkepanjangan, kadang rate limit yang membanjiri. Failover otomatis adalah pertahanan pertama: deteksi kegagalan, alihkan target, lalu ulangi request ke provider cadangan.

Konfigurasi fallback di 9router bersifat deterministik — urutannya dieksekusi sesuai urutan deklarasi:

routes:
  - name: chat-main
    match:
      intent: general_chat
    target:
      model: gpt-4o
      provider: openai-prod
      fallback:
        - model: claude-3-5-sonnet
          provider: anthropic-prod
        - model: gpt-4o-mini
          provider: azure-openai-prod

Jika gpt-4o gagal, request dipindahkan ke claude-3-5-sonnet, lalu ke gpt-4o-mini. Satu hal yang perlu diperhatikan: fallback bukan untuk semua error. Error 4xx seperti API key yang tidak valid atau prompt yang ditolak tidak akan memicu failover — request-nya memang salah dan tidak akan pernah berhasil di provider lain. Failover hanya untuk error yang bersifat transien: 5xx, timeout, dan rate limit.

Untuk memantau kondisi tiap route secara langsung, gunakan perintah status 9router status routes:

9router status routes
9router status route chat-main --show-latency

Output perintah tersebut menampilkan skor kesehatan provider, jumlah request yang di-failover, dan error terakhir. Ini gambaran cepat untuk memutuskan apakah perlu intervensi manual.

#Backup Routes: Fallback Level Route

Failover di atas bekerja dalam satu route. Backup route adalah level yang lebih tinggi: seluruh definisi route — termasuk match dan policy — punya kembarannya sendiri. Ini penting ketika kegagalan bukan pada satu model, melainkan pada satu jalur routing secara keseluruhan, misalnya policy rate limit yang salah diterapkan atau classifier intent yang error.

routes:
  - name: chat-primary
    match:
      intent: general_chat
    target:
      model: gpt-4o
      provider: openai-prod
    policy:
      rate_limit: 1000
 
  - name: chat-backup
    match:
      intent: general_chat
    target:
      model: claude-3-5-haiku
      provider: anthropic-prod
    policy:
      rate_limit: 200

Dengan pola ini, backup route membawa konfigurasi lengkapnya sendiri. Backup bisa diberi batas kapasitas lebih kecil karena biasanya berbagi kuota provider dengan route lain. Ketika chat-primary masuk status error, 9router mengarahkan traffic ke chat-backup sampai route utama pulih — dan pengguna tidak menyadari bahwa providernya berganti.

#Degraded Mode: Melayani Sedikit Daripada Tidak Sama Sekali

Terkadang tidak ada backup yang cukup kuat menanggung seluruh beban. Di situlah degraded mode berperan: gateway tetap melayani, tetapi dengan kapasitas yang sengaja diturunkan. Prinsipnya, availability lebih penting daripada kualitas — respons yang lebih pendek tetap lebih baik daripada tidak ada respons sama sekali.

routes:
  - name: chat-primary
    match:
      intent: general_chat
    target:
      model: gpt-4o
      provider: openai-prod
    degraded:
      enabled: true
      fallback_model: gpt-4o-mini
      max_tokens: 256
      cache_ttl: 10m
      response_on_failure: "Layanan sedang sibuk, silakan coba beberapa saat lagi."

Ketika mode ini aktif, 9router mengganti model dengan yang lebih murah dan cepat, memotong max_tokens untuk memperpendek waktu respons, dan mengaktifkan cache dengan TTL 10 menit agar permintaan identik tidak perlu memanggil provider. Hanya jika semua jalan buntu — provider down dan cache kosong — respons penggantian dikirim. Status mode ini bisa dicek kapan saja dengan 9router status degraded. Degraded mode bukan kegagalan desain; ini keputusan sadar untuk memilih kualitas lebih rendah daripada sistem mati total.

#Circuit Breaker: Menghentikan Amplifikasi Kegagalan

Bayangkan sebuah provider down, lalu jutaan request berulang kali memanggilnya dan menunggu timeout. Itu bukan hanya sia-sia — itu amplifikasi kegagalan yang bisa menjatuhkan bagian sistem lain yang sehat. Circuit breaker mencegah hal ini dengan memutus jalur secara sementara setelah ambang kegagalan terlampaui.

circuit_breaker:
  enabled: true
  failure_threshold: 5
  recovery_timeout: 30s
  half_open_max: 1

Circuit breaker bekerja seperti saklar tiga posisi:

• Closed: normal. Setiap kegagalan menambah counter.
• Open: setelah failure_threshold tercapai, jalur tertutup. Semua request langsung dialihkan ke fallback tanpa menunggu timeout, sehingga tidak ada request yang menggantung.
• Half-open: setelah recovery_timeout berlalu, satu request uji dikirim. Jika sukses, saklar kembali ke closed. Jika gagal, kembali ke open.

Dengan half_open_max: 1, hanya satu request percobaan yang diizinkan masuk — mencegah ledakan request langsung ketika provider baru mulai pulih.

#Incident Response untuk Kegagalan Routing

Otomasi menangani banyak hal, tetapi tidak semuanya. Insiden tetap perlu ditangani manusia, dan yang membedakan tim matang adalah cara mereka menanganinya. Urutan yang benar:

1. Deteksi — alert memberi tahu bahwa fallback rate melonjak. Alerting inilah yang akan dibangun di episode 20.
2. Triase — tentukan ini insiden routing (konfigurasi 9router salah) atau insiden provider (penyedia yang down).
3. Mitigasi — jika provider yang down, nonaktifkan route utama agar tidak menumpuk retry, lalu biarkan fallback menanggung beban.
4. Komunikasi — beri tahu stakeholder internal dan, jika perlu, pengguna.
5. Postmortem — dokumentasikan akar masalah dan langkah pencegahan agar tidak terulang.

Untuk mitigasi manual, 9router menyediakan perintah yang eksplisit dan meninggalkan jejak:

9router route disable chat-primary --reason "provider outage"
9router route enable chat-primary --after 15m
9router incident report 42 --severity major

--reason dan --after memastikan tindakan manual tercatat di audit dan route tidak lupa diaktifkan kembali. Insiden diberi nomor agar bisa dilacak, dihubungkan dengan alert, dan direview dalam postmortem.

#Penutup

Episode 18 mempersenjatai gateway kalian menghadapi kegagalan: failover deterministik antar provider, backup route dengan kapasitasnya sendiri, degraded mode yang menjaga availability, circuit breaker yang menghentikan amplifikasi kegagalan, dan incident response yang terstruktur.

Inti yang harus dibawa pulang:

• Failover harus punya urutan fallback yang deterministik dan hanya memicu pada error transien, bukan 4xx.
• Backup route adalah fallback level route dengan policy dan kapasitas sendiri — bukan sekadar ganti model.
• Degraded mode memilih melayani lebih sedikit daripada tidak melayani sama sekali.
• Circuit breaker mencegah provider yang down menumpuk retry dan menjatuhkan sistem yang sehat.
• Incident response yang terdokumentasi mengubah kekacauan menjadi langkah yang bisa dieksekusi.

Di episode 19 kita beralih dari menghadapi kegagalan ke mencegahnya masuk ke produksi: CI/CD dan deployment automation untuk konfigurasi 9router — validasi di pipeline, deploy otomatis perubahan route, dan staged rollout policy baru. Sampai jumpa!