Berbeda dengan sistem monolitik, layanan terdistribusi saling bergantung melalui jaringan yang latensinya tidak selalu konsisten. Karena itu, keputusan “menunggu atau berhenti” memiliki dampak sistemik, bukan lokal.
Dampak Timeout Terlalu Pendek
Timeout yang terlalu agresif sering terlihat aman karena sistem cepat “fail fast”. Namun pada praktiknya, pendekatan ini memiliki risiko tersembunyi.
Request yang sebenarnya masih bisa diproses akan diputus lebih awal. Akibatnya, klien menganggap layanan gagal dan memicu retry. Jika retry ini terjadi secara masif, sistem dapat mengalami lonjakan beban yang tidak perlu. Dalam kondisi ekstrem, hal ini menciptakan retry storm yang memperburuk keadaan awal.
Timeout pendek juga membuat sistem sensitif terhadap fluktuasi kecil, seperti garbage collection, spike CPU singkat, atau latensi jaringan sementara. Gangguan minor yang seharusnya bisa ditoleransi berubah menjadi kegagalan fungsional.
Dampak Timeout Terlalu Panjang
Timeout yang terlalu panjang terlihat “aman” karena memberi ruang bagi layanan untuk menyelesaikan pekerjaannya. Namun pendekatan ini membawa risiko lain yang tidak kalah serius.
Thread, connection pool, atau resource lain akan tertahan lebih lama. Dalam sistem dengan trafik tinggi, resource yang menunggu terlalu lama dapat menyebabkan antrian menumpuk dan throughput menurun. Kegagalan pun menjadi lebih lambat terdeteksi, sehingga sistem tampak hidup tetapi sebenarnya tidak responsif.
Timeout panjang juga menyulitkan mekanisme isolasi kegagalan. Layanan yang bermasalah tidak segera dilepaskan, sehingga efeknya merambat ke komponen lain.
Timeout sebagai Bagian dari Desain Sistem
Timeout tidak boleh diperlakukan sebagai angka default atau hasil tebakan. Ia harus selaras dengan karakteristik sistem, pola trafik, dan tujuan layanan.
Dalam praktik yang matang, timeout sering dikombinasikan dengan mekanisme lain seperti circuit breaker, retry dengan batasan, dan fallback logic. Timeout berperan sebagai pemicu keputusan, bukan satu-satunya alat perlindungan.
Faktor yang Perlu Dipertimbangkan Saat Menentukan Timeout
Ada beberapa pertimbangan teknis yang seharusnya menjadi dasar penentuan timeout dalam sistem terdistribusi:
1. Distribusi Latency Nyata
Timeout sebaiknya didasarkan pada data latency aktual, bukan rata-rata. Tail latency sering lebih relevan dibanding nilai median.
2. Karakteristik Operasi
Operasi read ringan dan operasi write kompleks tidak layak disamakan. Masing-masing membutuhkan toleransi waktu yang berbeda.
3. Dampak Retry terhadap Sistem
Timeout pendek tanpa kontrol retry hanya memindahkan masalah, bukan menyelesaikannya.
4. Ketersediaan Fallback
Jika ada fallback yang aman, timeout dapat lebih agresif. Tanpa fallback, timeout terlalu pendek justru merusak pengalaman pengguna.
Hubungan Timeout dengan Stabilitas Sistem
Stabilitas sistem tidak hanya ditentukan oleh kemampuan menangani beban, tetapi juga oleh kemampuan melepaskan beban yang bermasalah. Timeout yang tepat membantu sistem “mengakui kegagalan” secara cepat dan terkendali.
Sebaliknya, timeout yang salah konfigurasi menciptakan ilusi stabilitas atau kepanikan berlebihan. Keduanya sama-sama berbahaya dalam skala besar.
Timeout Bukan Angka, Tapi Kebijakan Teknis
Timeout management adalah keputusan arsitektural, bukan sekadar konfigurasi. Ia mencerminkan bagaimana sistem memandang kegagalan, ketidakpastian jaringan, dan batas toleransi operasional.
Sistem terdistribusi yang stabil bukanlah sistem tanpa timeout, melainkan sistem dengan timeout yang dirancang berdasarkan data, konteks, dan dampak lintas komponen.
Tidak ada komentar:
Posting Komentar