Konteks dan cakupan
Ini menguji perancangan protokol pada batas API. Dokumen yang dirujuk adalah Internet-Draft aktif yang diterbitkan pada 23 Mei 2026, bukan RFC; nyatakan status tersebut sebelum menggunakannya. Rancangan harus tetap aman meskipun suatu penerapan hanya mengadopsi sebagian dari proposal.
Apa yang dievaluasi oleh pewawancara
- Perbedaan yang tepat antara metadata kebijakan dan kuota yang tersedia saat ini.
- Penguraian structured-field, beberapa jendela waktu (multiple windows), unit kuota, dan kunci partisi.
- Interaksi dengan 429, Retry-After, gateway, CDN, dan respons cache yang basi (stale).
- Risiko privasi dan denial-of-service dari mengekspos batasan.
- Backoff klien yang memperlakukan petunjuk sebagai hal yang tidak mengikat serta mentoleransi bidang yang hilang atau salah format.
Struktur jawaban yang disarankan
Tentukan dimensi kuota dan kepemilikannya terlebih dahulu. Tunjukkan satu respons yang berisi kebijakan dan batas saat ini, lalu jelaskan bagaimana klien menjadwalkan pekerjaan. Tambahkan aturan cache dan perantara, batasan keamanan, observabilitas, serta rencana peluncuran dengan feature flag sehingga draf dapat berubah tanpa merusak klien.
Pembahasan mendalam: membuat header berguna tanpa menjanjikan kapasitas
Memisahkan kebijakan dari status saat ini
RateLimit-Policy menjelaskan kuota bernama, seperti "tenant";q=1000;w=60. RateLimit melaporkan kuota yang tersedia dan jendela waktu efektif, misalnya "tenant";r=420;t=23. Suatu kebijakan dapat berisi beberapa item dan jendela waktu yang bervariasi. Server tetap memegang otoritas: nilai-nilai ini adalah petunjuk (hints), bukan sewa (lease) atau jaminan tingkat layanan.
Menentukan semantik partisi dan unit
Dokumentasikan apakah satu unit kuota berarti satu permintaan, bita, token, atau operasi berbobot. Kunci partisi dapat membedakan penyewa atau sumber daya, tetapi jangan pernah memasukkan email, ID pengguna mentah, atau rahasia ke dalam header. Jaga agar nama kebijakan tetap stabil dan memiliki versi; mengubah unit tanpa mengubah pengenal kebijakan membuat pengaturan laju permintaan klien (client pacing) menjadi tidak aman.
Mengoordinasikan 429 dan Retry-After
Kembalikan Retry-After saat server mengetahui kapan permintaan yang ditolak dapat dicoba lagi. Jika kedua bidang ada, klien memprioritaskan Retry-After; RateLimit membantu mengatur laju pekerjaan di masa mendatang. Draf ini tidak memerlukan algoritma throttling tertentu, sehingga klien masih memerlukan exponential backoff berbatas atas, jitter, tenggat waktu (deadlines), dan aturan idempotensi untuk operasi tulis.
Memperlakukan cache dan perantara sebagai partisipan
Nilai RateLimit pada respons yang di-cache mungkin sudah basi dan harus diabaikan jika respons memiliki usia saat ini (current age) yang positif. Perantara yang tidak memahami semantik kuota tidak boleh membuat respons terlihat lebih longgar. Gateway yang menerapkan batasan lebih ketat dapat mengomunikasikan kebijakan yang lebih ketat tersebut, sementara telemetri mencatat keputusan asal (origin) dan gateway secara terpisah.
Melindungi ketersediaan dan privasi
Jangan mengekspos jendela kuota besar yang mengungkapkan volume lalu lintas atau memungkinkan penyerang memperkuat permintaan. Batasi rasio antara kuota yang tersedia dan jendela waktu efektif, validasi structured fields yang masuk, dan abaikan nilai yang salah format. Menurunkan nilai yang diiklankan selama saturasi diperbolehkan, tetapi klien harus tetap menangani penolakan bahkan ketika petunjuk terakhir terlihat sehat.
Contoh jawaban
“Saya akan membuat versi kebijakan bernama per penyewa dan operasi, menentukan unitnya, serta memancarkan metadata kebijakan secara terpisah dari kuota tersisa saat ini. Karena draf ini adalah Internet-Draft, klien memperlakukan kedua bidang sebagai petunjuk opsional. Retry-After mengontrol permintaan yang ditolak; RateLimit mengatur laju pekerjaan di masa mendatang. CDN menandai nilai yang di-cache sebagai basi, gateway tidak pernah membuat batas origin tampak lebih longgar, dan kunci partisi tidak berisi pengenal. SDK mengurai structured fields secara defensif, menggunakan jitter dan antrean bersama, serta mengekspos metrik untuk batas yang diiklankan versus yang diterapkan sebelum kita mengaktifkan kontrak secara bertahap.”
Pola kegagalan umum dan perbaikannya
- Menyebut draf sebagai RFC → Catat statusnya sebagai Internet-Draft dan isolasi di balik kontrak berversi.
- Menggunakan kuota tersisa sebagai izin mutlak → Perlakukan sebagai petunjuk; server mungkin masih menolak di bawah kondisi saturasi.
- Mengembalikan pengenal pengguna dalam kunci partisi → Gunakan nama yang buram (opaque) dengan kardinalitas rendah dan tinjau paparan privasi.
- Mempercayai header yang di-cache → Abaikan nilai yang basi dan biarkan origin yang menegakkan batas.
- Mencoba ulang setiap 429 secara langsung → Patuhi
Retry-After, tambahkan jitter, dan tegakkan idempotensi khusus metode.
Rubrik penilaian dan pemeriksaan mandiri
Nilai pemisahan kebijakan/status, unit dan partisi, interaksi 429, perilaku cache, privasi, pengaturan laju klien, keamanan peluncuran, dan metrik. Jawaban yang kuat menjelaskan arti setiap header, apa yang tidak dapat dijaminnya, dan bagaimana klien bersikap ketika bidang tidak ada, basi, atau salah format.
Pertanyaan lanjutan dan perluasan
Bagaimana jika suatu respons memiliki dua jendela waktu?
Pilih batasan yang akan habis lebih dulu untuk pengaturan laju permintaan, sambil tetap mempertahankan semua item untuk observabilitas. SDK tidak boleh menggabungkan (collapse) jendela dengan unit atau kunci partisi yang berbeda secara diam-diam.
Haruskah respons yang berhasil menyertakan RateLimit?
Boleh saja, tetapi klien tidak boleh berasumsi bahwa setiap respons memuatnya. Pancarkan hanya jika berguna untuk produk dan pastikan cache tidak dapat mengubah nilai lama menjadi janji saat ini.
Bagaimana cara meluncurkan draf yang masih dapat berubah?
Negosiasikan profil header atau versi kebijakan, catat fallback pengurai (parser fallbacks), lakukan canary berdasarkan versi SDK, dan pertahankan perilaku 429 serta Retry-After tetap stabil sementara bidang baru bersifat opsional.
Metrik mana yang membuktikan bahwa kontrak berfungsi?
Lacak batas yang diiklankan dan diterapkan, keputusan header basi, tingkat 429, amplifikasi percobaan ulang, penundaan antrean, keberhasilan akhir, dan kardinalitas partisi yang aman bagi privasi berdasarkan gateway dan versi SDK.