Timeout adalah batas berapa lama satu pihak bersedia menunggu operasi. Nilai terlalu pendek menciptakan kegagalan semu ketika tujuan sebenarnya hampir selesai; nilai terlalu panjang menahan resource, memperburuk antrean, dan membuat pengguna tidak tahu apakah aman mencoba lagi.
Timeout mana yang sedang dibicarakan?
Satu request dapat memiliki connect timeout, TLS handshake timeout, response-header timeout, idle/read timeout, query timeout, dan deadline keseluruhan. Nilai yang tidak selaras menghasilkan perilaku aneh: client berhenti setelah tiga detik sementara server tetap bekerja satu menit, lalu retry menciptakan operasi kedua.
Dokumentasikan deadline pada kontrak dan siapa yang membatalkan kerja. Timeout bukan status bisnis. Respons dapat berhenti sementara efek tujuan masih berlangsung. Pelajari risiko sukses palsu dan kebalikannya: gagal transport meskipun efek terjadi.
Bagaimana membagi budget waktu end-to-end?
Mulai dari pengalaman atau proses bisnis: misalnya pengguna menunggu maksimal delapan detik. Sisihkan waktu untuk validasi, dua dependensi, serialisasi, dan margin jaringan. Jika dua call berjalan berurutan, masing-masing tidak boleh memakai delapan detik penuh. Propagasikan deadline agar pekerjaan downstream berhenti ketika hasil tidak lagi berguna.
| Bagian contoh | Budget | Catatan |
|---|---|---|
| Validasi | 0,5 detik | Gagal cepat untuk input |
| Layanan A | 2 detik | Dependensi utama |
| Layanan B | 3 detik | Operasi lebih berat |
| Margin dan respons | 2,5 detik | Variasi jaringan dan render |
Data apa yang dipakai menentukan timeout?
Lihat distribusi latency, bukan rata-rata saja. P50 menggambarkan pengalaman umum; p95 atau p99 menunjukkan ekor yang memengaruhi kapasitas. Pisahkan waktu normal, peak, dan saat dependensi menurun. Kemudian bandingkan dengan nilai bisnis serta biaya menunggu. Angka timeout harus direview setelah pola beban berubah.
Jangan mengutip target performa produk tanpa laporan uji yang dapat diperiksa. Buat baseline pada lingkungan sendiri dan masukkan latency ke observability integrasi.
Bagaimana timeout berinteraksi dengan retry?
Retry setelah timeout berbahaya bila client tidak tahu apakah operasi pertama selesai. Gunakan idempotency key atau status lookup untuk operasi berefek. Retry juga harus muat dalam deadline keseluruhan; tiga percobaan masing-masing sepuluh detik tidak cocok untuk pengalaman delapan detik.
Tambahkan backoff dan jitter agar banyak client tidak mengulang bersamaan. Bedakan connect failure yang mungkin aman diulang dengan timeout setelah body dikirim. Gunakan panduan retry untuk mengklasifikasikan error sementara dan permanen.
Apa yang perlu diketahui pengguna dan operator?
Pesan harus menjelaskan apakah request ditolak sebelum proses, status belum diketahui, atau pekerjaan dilanjutkan asinkron. Berikan ID bisnis atau cara memeriksa hasil tanpa memaparkan detail internal. Operator membutuhkan nama dependensi, tahap, durasi, deadline, serta jumlah percobaan untuk diagnosis.
Jika hasil tidak pasti, jangan menyuruh pengguna langsung mengulang tanpa kontrol duplikasi. Nyatakan ketidakpastian dan langkah verifikasi.
Skenario timeout apa yang harus diuji?
- Koneksi tidak dapat dibuat.
- Header lambat tetapi body belum dikirim.
- Tujuan selesai setelah client berhenti menunggu.
- Satu dependensi mengambil seluruh budget.
- Pembatalan tidak menghentikan pekerjaan downstream.
- Retry bersamaan menciptakan lonjakan beban.
Platform seperti NitroNet dapat membantu memodelkan jalur sukses dan gagal, tetapi artikel ini tidak menyatakan angka atau mekanisme timeout internal. Evaluasi desain bersama circuit breaker dan runbook insiden.
Bangun test non-production yang memanggil tiga dependensi secara berurutan. Tambahkan latency terkontrol pada masing-masing layanan dan amati kapan client, proses utama, serta dependency berhenti. Tujuannya menemukan pekerjaan yatim dan budget yang tumpang tindih.
- Tetapkan satu deadline bisnis lalu bagi budget tanpa memberi setiap call batas keseluruhan penuh.
- Perlambat layanan pertama dan pastikan layanan berikutnya tidak dimulai setelah budget habis.
- Putus koneksi setelah request terkirim dan periksa apakah efek tujuan sebenarnya terjadi.
- Uji propagasi cancellation sampai query atau pekerjaan downstream yang masih berjalan.
- Jalankan retry dengan backoff dan pastikan seluruh percobaan tetap berada dalam deadline.
- Kirim beban bersamaan untuk melihat apakah timeout panjang menahan connection pool serta worker.
- Tampilkan hasil unknown secara berbeda dari rejected dan confirmed failed kepada pengguna.
- Catat latency distribution, tahap timeout, resource tertahan, dan tindakan operator yang diperlukan.
Gunakan hasil untuk menetapkan timeout per operasi, bukan satu angka global. Perubahan dependency, volume, atau service tier harus memicu review. Bila hasil setelah timeout tidak pasti, sediakan identitas serta pemeriksaan status dan cegah retry menciptakan efek ganda. Failure yang cepat hanya berguna bila maknanya benar.
Uji dengan latency bertingkat, respons yang berhenti di tengah, dan tujuan yang menyelesaikan operasi sesaat setelah caller menyerah. Catat durasi koneksi, pengiriman, waktu tunggu respons, serta batas keseluruhan secara terpisah. Pastikan sisa anggaran waktu diteruskan ke dependensi agar pekerjaan tidak terus berlangsung tanpa manfaat. Untuk operasi mutasi, gunakan identitas idempoten atau pemeriksaan status sebelum mengulang. Dashboard perlu membedakan timeout lokal, pembatalan caller, dan timeout dari tujuan karena tindakan perbaikannya tidak sama.