Petunjuk dan cakupan
Ini menguji batas protokol dari rate limiting, bukan sekadar penghitung Redis. RFC 6585 mendefinisikan 429 untuk terlalu banyak permintaan dalam suatu periode dan mengizinkan Retry-After; RFC 9110 mendefinisikan detik dan tanggal HTTP. Ubah semantik tersebut menjadi perilaku yang dapat dijalankan oleh klien dengan aman.
Hal yang dievaluasi oleh pewawancara
- Kunci batas, jendela waktu (windows), kuota, dan bidang respons yang menjelaskan siapa yang dibatasi dan kapan pemulihan dimungkinkan.
- Body 429 yang konsisten, Retry-After, ID permintaan, dan detail kuota yang aman.
- Penguraian (parsing) detik atau tanggal oleh klien, jitter, batas waktu (deadlines), dan anggaran percobaan (attempt budgets).
- Batasan percobaan ulang untuk penulisan non-idempoten, pekerjaan asinkron, dan batas waktu jaringan (network timeouts).
- Metrik untuk hit batas, waktu pemulihan, amplifikasi retry, dan keberhasilan akhir.
Struktur jawaban yang direkomendasikan
Tentukan dimensi batas dan kelas kesalahan. Tunjukkan respons 429 dan aturan Retry-After. Klien menggunakan header, jenis permintaan, dan anggaran lokal untuk menunggu, membatalkan, atau beralih ke pekerjaan asinkron; setiap percobaan ulang menggunakan exponential backoff dengan batas atas (capped) beserta jitter. Akhiri dengan tanggung jawab gateway, aplikasi, SDK, dan operasi bisnis serta pengujian injeksi kegagalan (fault-injection).
Pembahasan mendalam: dari respons hingga percobaan ulang
Buat pembatasan dapat dijelaskan
Tetapkan kunci batasan berdasarkan penyewa, kredensial, IP, endpoint, atau sumber daya global. Kembalikan jenis kesalahan yang stabil, ID permintaan, dan alasan yang aman. Jika beberapa pembatas terpicu bersamaan, gunakan waktu tunggu terlama yang diketahui tanpa mengungkapkan kuota penyewa lain.
Hasilkan Retry-After dengan benar
Penundaan (delay) menunjukkan setidaknya berapa detik harus menunggu; tanggal HTTP menunjukkan waktu pemulihan. Hitung jendela internal menggunakan monotonic clock, bulatkan ke atas, dan batasi nilainya (cap). Klien tetap memerlukan waktu tunggu minimum dan jitter karena tanggal dapat dipengaruhi oleh perbedaan waktu jam (clock skew) atau proksi.
Urai dan lakukan backoff pada klien
Patuhi Retry-After terlebih dahulu; jika tidak ada atau tidak valid, gunakan exponential backoff dengan batas atas. Berikan setiap permintaan logis tenggat waktu total dan anggaran percobaan. Koordinasikan pekerjaan yang berjalan bersamaan (konkuren) melalui antrean bersama atau anggaran token agar banyak tugas tidak aktif kembali secara bersamaan.
Hormati batasan idempotensi
GET, HEAD, serta PUT atau DELETE yang secara eksplisit idempoten biasanya dapat dicoba ulang. POST memerlukan kunci idempotensi dan semantik server yang sesuai. Jika respons hilang setelah eksekusi, lakukan kueri status atau gunakan kembali kunci yang sama alih-alih membuat efek samping kedua.
Amati pemulihan, bukan hanya kesalahan
Catat dimensi batasan, jumlah 429, distribusi Retry-After, waktu tunggu klien, amplifikasi retry, keberhasilan akhir, dan pembatalan (abandonment). Segmentasikan berdasarkan versi SDK dan penyewa untuk membedakan percobaan ulang langsung dari pertumbuhan lalu lintas yang sah.
Contoh jawaban
"Saya akan membatasi laju permintaan berdasarkan penyewa, kredensial, dan endpoint serta mengembalikan jenis kesalahan yang stabil, ID permintaan, alasan yang aman, dan Retry-After. Server menghitung penundaan jendela monotonik, membulatkannya ke atas, dan membatasinya. SDK mengurai Retry-After terlebih dahulu dan jika tidak ada akan menggunakan exponential backoff dengan jitter; setiap permintaan logis memiliki batas waktu dan batas percobaan. GET dapat dicoba ulang; POST memerlukan kunci idempotensi atau kueri status. Saya akan memantau respons 429, distribusi waktu tunggu, amplifikasi retry, keberhasilan akhir, dan pembatalan, lalu menjalankan pengujian multi-klien yang tersinkronisasi untuk memverifikasi pemulihan yang lancar."
Pola kegagalan umum dan perbaikannya
- Mencoba ulang setiap kegagalan → Klasifikasikan berdasarkan status, semantik metode, dan jenis kesalahan.
- Mengabaikan format Retry-After → Dukung format detik dan tanggal HTTP serta tolak nilai yang tidak valid secara aman.
- Percobaan ulang langsung per utas (thread) → Bagikan anggaran, antrean, dan jitter.
- Mengasumsikan POST bersifat idempoten → Gunakan kunci idempotensi, kueri status, atau hasil eksplisit tanpa percobaan ulang.
- Hanya memantau jumlah 429 → Ukur waktu tunggu, amplifikasi, keberhasilan akhir, dan pembatalan.
Rubrik penilaian dan pemeriksaan mandiri
Jawaban yang kuat mencakup kunci batasan, semantik 429, pembuatan dan penguraian Retry-After, backoff dengan jitter, batas waktu, idempotensi, koordinasi konkurensi, detail kuota yang aman, kepemilikan komponen, dan metrik validasi.
Tanyakan: Apakah klien mengetahui kapan pemulihan dimungkinkan? Bagaimana jika jam berbeda? Bagaimana jika header tidak ada? Bisakah percobaan ulang menduplikasi efek samping? Bagaimana tugas-tugas konkuren disebarkan? Apa yang membuktikan bahwa pemulihan telah membaik?
Pertanyaan lanjutan dan pengembangan
Haruskah Retry-After menggunakan detik atau tanggal?
Keduanya merupakan bentuk HTTP yang valid. Detik cocok untuk jendela waktu yang pendek dan menghindari perbedaan jam; tanggal dapat menyatakan titik waktu pemulihan yang pasti. Jaga agar keluaran server tetap konsisten sambil memastikan penguraian SDK kompatibel dengan keduanya serta mampu menangani nilai yang telah kedaluwarsa.
Jika gateway dan aplikasi sama-sama membatasi, waktu tunggu mana yang dikembalikan?
Waktu tunggu yang terlihat oleh klien harus mencakup semua batasan yang diketahui, biasanya yang terlama, disertai dengan ID permintaan. Telemetri internal mencatat setiap lapisan sehingga penolakan di tingkat gateway tidak salah dianggap berasal dari aplikasi.
Bisakah klien mencoba ulang tanpa Retry-After?
Hanya jika metode dan semantik kesalahan mengizinkannya, batas waktu masih tersisa, dan anggaran backoff lokal mencukupi. Gunakan backoff dengan jitter dan batas atas; untuk penulisan yang tidak dapat dicoba ulang, kembalikan status yang dapat dikueri atau kegagalan eksplisit.
Bagaimana cara menguji badai retry?
Sinkronkan banyak klien untuk memicu 429, lalu masukkan header yang tidak valid, perbedaan jam (clock skew), batas waktu koneksi, dan jitter pemulihan. Amati kurva kedatangan, amplifikasi, waktu pemulihan, dan keberhasilan akhir.