Petunjuk dan konteks
Sebuah API mengembalikan 429 Too Many Requests setelah terjadi lonjakan lalu lintas (traffic spike). Jelaskan batas tanggung jawab dari kode status ini, cara membaca Retry-After, permintaan mana yang dapat dicoba ulang, dan cara mencegah klien mengubah kelebihan beban menjadi kegagalan beruntun (cascading failure).
Hal yang dievaluasi pewawancara
- Pemahaman terhadap 429 sebagai sinyal pembatasan laju (rate-limit), bukan kegagalan server permanen.
- Penanganan kedua format Retry-After dan skenario header yang tidak ada dengan benar.
- Penggabungan idempoten, batas waktu (deadline), dan efek samping bisnis saat memutuskan untuk mencoba lagi.
- Perlindungan terhadap layanan menggunakan exponential backoff, jitter, budget, dan kontrol laju (rate control).
Pertanyaan untuk diklarifikasi sebelum menjawab
- Apakah batasannya per pengguna, token, penyewa (tenant), IP, atau sumber daya bersama?
- Apakah respons memuat Retry-After, dan dapatkah klien mempercayai jamnya?
- Apakah metode dan operasi bisnis bersifat idempoten, atau apakah ada kunci idempoten (idempotency key)?
- Apakah ada batas waktu keseluruhan (overall deadline), batas percobaan ulang, dan budget percobaan ulang (retry budget)?
- Apakah layanan mengekspos kuota, sisa kapasitas, atau ID permintaan?
Kerangka jawaban 30 detik
Saya memperlakukan 429 sebagai umpan balik batas laju dan membaca Retry-After, yang dapat berupa hitungan detik atau tanggal HTTP. Saya menghormati anjuran server dalam batas backoff klien yang aman dan menambahkan jitter. Saya hanya mencoba ulang secara otomatis pada operasi yang idempoten atau operasi yang dilindungi oleh idempotency key, dengan batasan deadline, jumlah percobaan, dan budget. Tanpa Retry-After, saya menggunakan exponential backoff dengan jitter; 429 yang berulang akan menghentikan proses dan mengembalikan kontrol ke pemanggil.
Pembahasan mendalam langkah demi langkah
Langkah 1: Konfirmasikan semantik 429
RFC 6585 mendefinisikan 429 untuk permintaan yang terlalu banyak dalam periode tertentu dan mengizinkan Retry-After. Ini memberitahu klien untuk mengurangi laju; status ini tidak boleh diperlakukan seperti 500 dan dicoba ulang seketika.
Langkah 2: Parsing Retry-After
Retry-After dapat berupa bilangan bulat detik non-negatif atau tanggal HTTP. Untuk tanggal, gunakan Date respons atau jam yang tepercaya untuk memperkirakan penundaan, serta batasi nilai negatif, nilai yang terlampau besar, atau format yang salah.
Retry-After: 8
Retry-After: Wed, 02 Aug 2026 02:00:00 GMTLangkah 3: Tentukan apakah pengiriman ulang aman
Metode yang aman seperti GET dan HEAD biasanya dapat dicoba ulang. Penulisan (write) memerlukan semantik idempoten, idempotency key, atau deduplikasi di sisi server. Metode yang sama pun dapat memiliki efek samping seperti pembebanan biaya, pengiriman email, atau pembuatan tugas.
Langkah 4: Hitung penundaan dan backoff
Patuhi Retry-After terlebih dahulu, kemudian terapkan batas atas exponential-backoff klien dan jitter acak. Jitter mencegah banyak klien terbangun pada saat yang bersamaan. Penantian harus sesuai dengan deadline permintaan, bukan memperpanjangnya tanpa batas.
Langkah 5: Batasi amplifikasi percobaan ulang
Tetapkan batas percobaan per permintaan, budget percobaan ulang global, dan batas konkurensi. Kurangi laju untuk sumber daya yang terus-menerus mengembalikan 429; gunakan antrean lokal atau circuit breaker jika diperlukan agar percobaan ulang tidak menghabiskan kapasitas lalu lintas normal.
Langkah 6: Pisahkan tanggung jawab klien dan server
Server menyediakan sinyal batas yang eksplisit dan bidang yang dapat diobservasi. Klien menghormati sinyal tersebut, melakukan backoff, dan berhenti. Setelah pemulihan, naikkan lalu lintas secara bertahap daripada melepaskan semua permintaan yang menunggu secara bersamaan.
Langkah 7: Catat hasil dan lakukan perbaikan
Lacak tingkat 429, distribusi Retry-After, tingkat keberhasilan akhir, jumlah percobaan ulang, dan pembatalan akibat deadline. Gunakan data tersebut untuk menyesuaikan kuota, budget klien, dan peringatan (alerts), bukan memperlakukan 429 sebagai kegagalan satu permintaan saja.
Contoh jawaban berkualitas tinggi
Pertama-tama saya akan mengonfirmasi dimensi batas dan header respons. Dengan Retry-After: 8, klien menunggu setidaknya delapan detik; dengan tanggal HTTP, klien menghitung penundaan menggunakan jam tepercaya dan batas maksimum. Pencarian pesanan dengan idempotency key dapat dicoba ulang secara otomatis, sedangkan pembuatan pembebanan biaya tanpa deduplikasi harus dikonfirmasi oleh lapisan bisnis. Saya menggunakan exponential backoff dengan random jitter, batas tiga kali percobaan per permintaan, budget percobaan ulang global, dan deadline keseluruhan. Kode 429 yang terus-menerus muncul akan menurunkan konkurensi dan menjeda antrean sehingga percobaan ulang tidak memperparah kelebihan beban. Metrik mencakup tingkat 429, waktu tunggu, dan tingkat keberhasilan akhir untuk penyesuaian kuota serta peringatan.
Kesalahan umum
- Memperlakukan 429 seperti 500 dan langsung mencoba ulang dalam loop ketat.
- Hanya mendukung Retry-After format integer dan mengabaikan bentuk tanggal HTTP.
- Gagal membedakan operasi baca yang idempoten dari operasi tulis yang memiliki efek samping.
- Mengabaikan deadline, budget, atau batas konkurensi sehingga percobaan ulang membengkak tanpa batas.
- Memberikan penundaan tetap yang sama ke setiap klien sehingga menciptakan lonjakan percobaan ulang yang tersinkronisasi.
Pertanyaan lanjutan dan jawabannya
Pertanyaan lanjutan 1: Berapa lama Anda harus menunggu tanpa Retry-After?
Gunakan exponential backoff dengan jitter beserta batasan penundaan maksimum, batas percobaan, dan deadline total. Sesuaikan berdasarkan tingkat 429 dan kuota, alih-alih memilih satu nilai konstanta permanen.
Pertanyaan lanjutan 2: Bagaimana jika tanggal HTTP berada di masa lalu?
Perlakukan penundaan server sebagai nol tetapi tetap terapkan backoff lokal dan jitter, serta catat adanya masalah jam atau pembuatan tanggal di sisi server. Jangan meluncurkan percobaan ulang berkonkurensi tinggi hanya karena tanggal tersebut tidak valid.
Pertanyaan lanjutan 3: Bisakah POST dicoba ulang?
Hanya jika API mendefinisikan idempoten, menyediakan idempotency key, atau lapisan bisnis dapat melakukan deduplikasi. Jika tidak, kembalikan ke pemanggil untuk keputusan pengiriman ulang secara eksplisit.
Pertanyaan lanjutan 4: Bagaimana jika banyak instans berbagi satu kuota?
Koordinasikan budget percobaan ulang dan kontrol laju lintas proses atau pada cakupan tenant, menggunakan sinyal bersama untuk mengurangi konkurensi. Backoff per-instans tidak dapat mencegah kelebihan penggunaan agregat.
Pertanyaan lanjutan 5: Bagaimana cara menghindari lonjakan kelebihan beban lainnya selama pemulihan?
Naikkan antrean secara bertahap, pertahankan jitter dan batas konkurensi, serta naikkan laju hanya setelah mengamati kondisi 429 dan latensi. Jangan melepaskan semua permintaan yang menunggu sekaligus.
Pertanyaan lanjutan 6: Metrik apa yang membuktikan bahwa strategi ini berhasil?
Bandingkan tingkat 429, amplifikasi percobaan ulang, tingkat keberhasilan, latensi P95, pembatalan akhir, dan waktu pemulihan, yang disegmentasikan berdasarkan tenant atau sumber daya.