Petunjuk dan konteks
Platform ini memiliki ratusan instance gateway di berbagai wilayah. Tim produk memerlukan kuota request-per-second, konkurensi, dan kuota harian berdasarkan tenant, aplikasi, endpoint, dan paket langganan, dengan perubahan yang berlaku dalam hitungan menit. Satu tenant tidak boleh menghabiskan kapasitas bersama, namun API inti harus tetap tersedia selama gangguan singkat pada layanan kuota.
Wawancara ini menguji pemisahan control-plane/data-plane, model penghitungan, konsistensi distribusi, kompromi lintas wilayah, dan perilaku saat terjadi kegagalan. Envoy membedakan rate limiting lokal dan global, sementara RFC 9331 mendefinisikan field RateLimit HTTP; hubungkan protokol, kebijakan produk, dan keputusan runtime.
Hal yang dievaluasi oleh pewawancara
Cakup struktur kebijakan, versi dan persetujuan, kunci deskriptor, token bucket atau sliding window, tenant dengan lalu lintas tinggi (hot tenant), penghitungan lintas wilayah, distribusi konfigurasi, caching, fail-open versus fail-closed, header kuota, audit, dan biaya.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah kuota berupa batasan ketat (hard limit), peringatan lunak (soft alert), atau keduanya, dan apakah lalu lintas boleh melonjak (burst) atau meminjam kapasitas masa depan?
- Dimensi mana yang memerlukan presisi global dan mana yang mengizinkan aproksimasi regional terbatas?
- Berapa target propagasi dan rollback, serta berapa lama gateway dapat terputus sebelum kebijakan dianggap usang (stale)?
- Apakah respons yang melebihi batas harus menampilkan waktu coba lagi (retry timing), sisa kuota, dan event penagihan?
- Endpoint inti mana yang harus tetap berjalan selama pemadaman layanan pembatas kuota (limiter)?
Jawaban 30 detik
“Control plane menyimpan kebijakan yang telah disetujui dan diberi versi, mengompilasinya ke dalam deskriptor gateway, dan mendistribusikan delta. Data plane membuat keputusan lokal yang cepat; hanya dimensi yang memerlukan presisi global yang memanggil limiter bersama. Token bucket menyerap lonjakan lalu lintas dan penghitung (counters) diisolasi berdasarkan tenant dan endpoint. Kebijakan membawa TTL, checksum, dan versi rollback. Pilih fail-open atau fail-closed berdasarkan risiko endpoint, kembalikan informasi standar RateLimit, dan audit alasan keputusan tersebut.”
Pembahasan mendalam langkah demi langkah
Langkah 1: Tentukan kebijakan dan alur kerja rilis
Kebijakan berisi tenant, aplikasi, endpoint, jendela waktu (window), laju (rate), kapasitas, konkurensi, kuota harian, cakupan wilayah, dan prioritas. Gateway tidak boleh menginterpretasikan field produk arbitrer; control plane mengompilasinya menjadi deskriptor yang stabil.
policy v42:
subject: tenant:acme / app:billing
route: POST /invoices
rate: 200 requests/second
burst: 400
scope: globalRilis memerlukan persetujuan, pemeriksaan konflik statis, simulasi lalu lintas, dan versi yang ditandatangani. Simpan pembuat, alasan, dampak yang diharapkan, dan pointer rollback; jangan pernah menimpa versi yang telah diaudit.
Langkah 2: Pilih model penghitungan dan sharding
Gunakan token bucket lokal di gateway untuk lonjakan singkat. Limiter bersama dapat menghitung dimensi global berdasarkan deskriptor. Untuk kuota harian, gunakan penghitung jendela atomik (atomic window counters) atau kuota yang di-shard, dengan batas jendela yang eksplisit dan sumber jam (clock source).
Lakukan sharding berdasarkan tenant, aplikasi, dan endpoint agar satu kunci yang sering diakses (hot key) tidak menjadi bottleneck. Hot tenant dapat menerima token hierarkis, kapasitas yang dialokasikan sebelumnya, atau shard khusus, dengan penanganan eksplisit untuk kelebihan pemakaian singkat dan penagihan akhir.
Langkah 3: Distribusikan kebijakan dengan konsistensi
Kirimkan kebijakan yang telah dikompilasi secara streaming beserta versi dan checksum ke gateway. Hanya terima versi yang ditandatangani secara valid dan meningkat secara monoton; muat snapshot valid terakhir saat startup. Pembaruan yang hilang akan menandai gateway sebagai usang (stale) setelah TTL-nya habis dan memicu peringatan.
Utamakan distribusi lokal di dalam satu wilayah. Kebijakan lintas wilayah menggunakan versi global dan waktu efektif yang eksplisit. Rollback adalah versi baru lainnya, bukan menulis ulang riwayat; gateway melaporkan cakupan versi setelah memberikan konfirmasi (acknowledgement).
Langkah 4: Tangani konsistensi, lonjakan, dan keadilan
Penghitungan global yang tepat menambah latensi jaringan dan biaya shared-state. Alokasikan koordinasi yang kuat hanya untuk dimensi berisiko tinggi atau berbasis kontrak, dan izinkan bounded error di tempat lain. Sesuaikan kapasitas lonjakan dengan konkurensi backend; hanya meningkatkan bucket gateway tetap dapat membebani layanan backend secara berlebih.
Keadilan antar-tenant harus melindungi connection pool bersama. Gabungkan keputusan kuota dengan pembatas konkurensi (bulkheads), panjang antrean, dan prioritas. Catat apakah lalu lintas ditolak atau dimasukkan ke antrean beserta alasannya, sehingga pelanggan dapat mendiagnosis lebih dari sekadar angka tunggal.
Langkah 5: Tentukan kegagalan dan degradasi
Jika limiter tidak dapat dijangkau, endpoint baca-saja (read-only) berisiko rendah dapat menggunakan snapshot lokal terbaru dengan bounded fail-open; penulisan, penagihan, dan endpoint mahal menggunakan fail-closed atau batas lokal yang lebih ketat. Berikan masa kedaluwarsa pada setiap keputusan yang terdegradasi dan rekonsiliasi atau tandai hitungan perkiraan setelah pemulihan.
Uji coba restart gateway, clock drift, pesan duplikat, dan gangguan distribusi. Tolak snapshot yang rusak dan pertahankan versi valid terakhir; konfigurasi yang kosong tidak boleh dianggap sebagai kuota tak terbatas.
Langkah 6: Protokol, audit, dan observabilitas
Kembalikan semantik 429 yang stabil pada respons yang melebihi batas dan tampilkan informasi limit, remaining, dan reset yang dapat diinterpretasikan sesuai dengan RFC 9331. Untuk tenant yang tidak boleh melihat angka pasti, gunakan pesan berjenjang (tiered message). Catat versi kebijakan, deskriptor, wilayah, sumber penghitung, status degradasi, dan jejak permintaan secara internal.
Pantau cakupan versi, latensi keputusan, tingkat penolakan, hot keys, kesalahan hitungan, durasi degradasi, dan rollback. Evaluasi kebijakan baru dalam mode shadow dan bandingkan perubahan penolakan sebelum dirilis.
Contoh jawaban yang kuat
Saya akan mengompilasi kebijakan yang disetujui ke dalam deskriptor berversi dan mendistribusikan delta dari control plane. Gateway menggunakan token bucket lokal untuk latensi rendah, dan hanya memanggil layanan bersama untuk dimensi yang memerlukan presisi global. Kebijakan membawa tanda tangan, TTL, checksum, dan versi rollback, yang diisolasi berdasarkan tenant, aplikasi, endpoint, dan wilayah. Lakukan degradasi berdasarkan risiko endpoint, kembalikan 429 yang stabil beserta informasi RateLimit, dan catat versi, sumber penghitung, serta status aproksimasi.
Kesalahan umum
- Mengirim setiap permintaan ke penghitung pusat → latensi dan domain kegagalan meningkat → buat keputusan lokal dan koordinasikan secara global berdasarkan risiko.
- Menimpa konfigurasi → tidak ada audit atau rollback → gunakan persetujuan, tanda tangan, dan versi monotonik.
- Menetapkan laju tanpa lonjakan atau konkurensi → backend masih dapat kebanjiran trafik → gabungkan token, bulkheads, dan antrean.
- Selalu fail-open → penulisan dan penagihan menjadi tidak terbatas → degradasi berdasarkan risiko endpoint.
- Mengembalikan error yang tidak jelas → pelanggan tidak dapat menyesuaikan lalu lintas → sediakan status yang stabil, waktu reset, dan alasan yang dapat diaudit.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Mengapa tidak mewajibkan konsistensi yang kuat di semua tempat?
Konsistensi yang kuat memerlukan shared state dan round trip jaringan, yang mengurangi ketersediaan dan meningkatkan biaya. Alokasikan hal tersebut hanya untuk dimensi kontraktual atau yang kritis terhadap keamanan, dan publikasikan model bounded-error di tempat lain.
Pertanyaan lanjutan 2: Bagaimana Anda menangani lonjakan lintas wilayah?
Alokasikan token regional sebelumnya di bawah batas global. Lalu lintas bernilai tinggi dapat meminjam secara singkat, tetapi catat kapasitas yang dipinjam serta aturan pelunasan atau penagihan agar satu wilayah tidak mendominasi.
Pertanyaan lanjutan 3: Siapa yang bertanggung jawab atas keterlambatan propagasi?
Gateway menyimpan versi valid terakhirnya dan menandai dirinya usang (stale) sementara control plane melacak cakupan. Setelah TTL habis, perketat atau jeda berdasarkan risiko endpoint; jangan pernah diam-diam berubah menjadi kuota tak terbatas.
Pertanyaan lanjutan 4: Bagaimana Anda membuktikan bahwa kebijakan baru tidak merugikan pelanggan?
Jalankan evaluasi shadow dan pemutaran ulang data historis, bandingkan distribusi penolakan, latensi, dan tenant, tetapkan batasan otomatis (automated gates), lalu lakukan rilis canary secara terbatas dengan versi rollback satu klik.