Design Rate Limiter

Prompt latihan

1. Problem Statement, Functional Requirements, and Scale Assumptions

   Tentukan ruang lingkup Rate Limiter: perjelas apakah ini limiter di level API gateway atau middleware level aplikasi, apakah batas bersifat per-pengguna, per-IP, atau per-API-key, dan apakah batas bersifat tetap atau dapat dikonfigurasi secara dinamis. Nyatakan non-goal yang eksplisit: integrasi penagihan, manajemen kuota, dan penegakan SLA milik layanan terpisah. Tetapkan asumsi skala awal sebelum mengusulkan komponen.

2. Non-Functional Requirements

   Identifikasi NFR yang kritis untuk rate limiter: penambahan latensi yang rendah per request (limiter tidak boleh menurunkan hot path), ketersediaan tinggi (apa yang terjadi ketika limiter itu sendiri tidak tersedia, fail-open atau fail-closed?), konsistensi hitungan rate di seluruh instance terdistribusi, dan trade-off akurasi vs. performa untuk algoritma yang dipilih. Putuskan NFR mana yang merupakan persyaratan keras versus aproksimasi yang dapat diterima.

3. Quantitative Analysis

   Perkirakan angka-angka kunci: total klien unik, request per detik per klien, RPS global puncak, jejak memori per entri klien untuk token bucket (jumlah token, timestamp refill terakhir) versus sliding window (array penghitung atau entri sorted-set), total ukuran counter store pada jumlah klien Anda, dan laju pertumbuhan penyimpanan untuk audit log bila diperlukan.

4. API Design

   Rancang antarmuka rate limiter: tentukan apakah ia mengekspos endpoint pemeriksaan atau beroperasi sebagai middleware inline, seperti apa header respons rate limit (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After), bagaimana API konfigurasi memungkinkan aturan dibuat atau diperbarui per identitas klien, dan seperti apa bentuk respons untuk request yang ditolak (429 Too Many Requests dengan Retry-After).

5. High-Level Design

   Usulkan komponen utama: middleware atau layanan rate limiter, rule store (tempat konfigurasi batas berada), counter store (tempat hitungan request per klien berada), lapisan identifikasi klien (mengekstrak user ID, IP, atau API key dari request), dan titik integrasi dengan layanan backend. Deskripsikan jalur pemeriksaan yang sibuk: untuk setiap request masuk, bagaimana limiter memutuskan izinkan atau tolak dalam anggaran latensi?

6. Additional High-Level Design Prompts

   Perjelas tiga keputusan desain: (1) Bagaimana pembatasan multi-tier bekerja, apakah sistem menerapkan batas harian per-pengguna global dan batas burst per-endpoint dalam satu pemeriksaan, dan dalam urutan apa? (2) Bagaimana perubahan aturan disebarkan ke semua instance limiter yang berjalan tanpa memerlukan restart, push dari config service, poll, atau cache lokal dengan TTL pendek? (3) Bagaimana sistem menampilkan metrik rate limit hit untuk alerting terhadap penyalahgunaan atau lonjakan trafik yang tidak terduga?

7. Deep Dives

   Selami tiga area: (1) Token bucket vs. sliding window, bandingkan mekanika algoritma, jejak memori per klien (token bucket: ~24 byte untuk count + timestamp refill terakhir; sliding window: sorted-set dengan hingga N entri per window), perilaku burst (token bucket mengizinkan burst yang terakumulasi; penghitung sliding window meratakan trafik), dan kapan masing-masing menjadi pilihan yang tepat; (2) State rate terdistribusi, bandingkan counter store terpusat (Redis dengan INCR atomik) versus penghitung lokal dalam proses dengan sinkronisasi gossip berkala, apa jaminan konsistensi, mode kegagalan, dan biaya throughput dari masing-masing pendekatan; (3) Race condition, jelaskan mengapa pola GET-lalu-SET yang naif memungkinkan over-counting di bawah konkurensi, bagaimana Lua scripting Redis atau compare-and-swap menghilangkan race tersebut, dan bagaimana clock drift antar node terdistribusi memengaruhi akurasi sliding window.

8. Final Review Handoff Readiness

   Rangkum desain end-to-end: algoritma yang dipilih dan alasannya, teknologi counter store dan jaminan konsistensinya, keputusan fail-open atau fail-closed serta dampak bisnisnya, dan arsitektur pembatasan multi-tier bila berlaku. Identifikasi risiko terbuka terbesar yang tersisa (ketidaktersediaan counter store, clock drift, keterlambatan propagasi aturan) dan usulkan strategi peluncuran termasuk feature flag, mode shadow, dan pengaktifan bertahap per endpoint.

Preview solusi

Jalur referensi Solusi Rate Limiter adalah materi belajar yang bersifat read-only. Gunakan untuk membandingkan desain Anda sendiri dengan sebuah jalur referensi yang ringkas sebelum memulai latihan atau setelah Anda menyelesaikan satu putaran. Tempatkan rate limiter sebagai middleware di API gateway sehingga semua traffic melewati satu titik penegakan (enfor…