Seorang pengembang yang sedang menguji sistem perutean suara (voice-routing) menambahkan karantina sementara yang memaksa panggilan berikutnya menggunakan jalur berbeda selama 300 detik setelah kegagalan. Penyesuaian ini menghentikan perangkat lunak agar tidak mencoba rute rusak yang sama secara berulang, sehingga mengurangi kemungkinan terjadinya gangguan beruntun (cascade outage).

Mengapa logika lama menjadi masalah

Router asli mengikuti aturan yang kaku: ketika sebuah workstation sibuk, ia hanya mencoba jalur yang sama lagi. Jika jalur tersebut terus gagal, sistem akan mencatat kesalahan tersebut tetapi tidak pernah mengubah perilakunya. Dalam praktiknya, satu titik kegagalan (single point of failure) dapat terus memblokir panggilan karena perangkat lunak terus berputar pada jalan buntu yang sama.

Mekanisme karantina baru

Pembaruan ini menambahkan tiga batasan:

  • Tidak permanen – penanda karantina akan kedaluwarsa setelah jendela waktu singkat.
  • Tidak global – ini hanya berlaku untuk jalur spesifik yang gagal, bukan untuk setiap rute.
  • Memori terbatas – sistem mencatat kegagalan dalam file lokal dan akan menghapusnya setelah jalur baru berhasil.

Saat upaya bicara (speech attempt) gagal, router akan menulis bendera (flag) “quarantined” untuk jalur tersebut. Selama 300 detik berikutnya, setiap permintaan yang masuk secara otomatis dialihkan ke jalur alternatif. Segera setelah permintaan berhasil di rute yang berbeda, bendera tersebut akan dihapus, memastikan perbaikan tidak bertahan lebih lama dari yang dibutuhkan.

Keuntungan dan konsekuensi

Keuntungan utamanya adalah ketahanan (resilience): gangguan sesaat tidak lagi meruntuhkan seluruh layanan. Dengan membatasi karantina selama lima menit, sistem menghindari hilangnya layanan jangka panjang sambil tetap memberikan waktu bagi jaringan untuk pulih.

Pendekatan ini membawa risiko. Gangguan jaringan singkat dapat memicu karantina yang memaksa panggilan melalui rute yang kurang optimal, sehingga meningkatkan latensi atau biaya. Jika jalur alternatif juga mengalami penurunan performa, sistem dapat berpindah-pindah antar rute, sehingga menciptakan ketidakstabilan. Operator memerlukan visibilitas terhadap penanda karantina untuk mengetahui apakah pengalihan rute tersebut disengaja atau merupakan gejala dari masalah yang lebih dalam.

Apa yang perlu diperhatikan selanjutnya

  • Metrik: Pantau frekuensi dan durasi karantina untuk melihat apakah jendela waktu 300 detik sudah sesuai.
  • Cakupan: Tim mungkin mencoba memperluas logika ini ke layanan lain yang mengalami masalah pola pengulangan (retry) statis.
  • Otomatisasi: Tambahkan peringatan ketika sebuah jalur berulang kali masuk ke karantina untuk mendorong pemeliharaan proaktif sebelum pengguna menyadari adanya masalah.

Pelajaran intinya sederhana: sistem yang tidak mencatat kegagalan terbarunya tidak dapat beradaptasi dengan lingkungan yang berubah. Dengan membuat riwayat kegagalan terlihat dan menindaklanjutinya—secara sementara—insinyur dapat menjaga layanan suara tetap berjalan lancar tanpa harus menunggu desain ulang skala penuh.

Sumber: postingan asli pengembang di dev.to.

Ikuti diskusinya: https://t.me/GyaanSetuAi