Burada ne görüyorsunuz

Ateşlediğin her request — butonla, space’e basılı tutarak ya da botlardan biriyle — aynı API’yi koruyan üç limiter’a birden kopyalanıyor. Üçü de aynı ortalamayı uyguluyor: 2 saniyelik bir window üzerinden sayılan saniyede N request. Farkı nasıl saydıkları; sınırlarda ne olacağını da bu belirliyor. İzin verilen request’ler API’ye uçuyor, reddedilenler 429 Too Many Requests olarak geri sekiyor.

Fixed window açığı

Fixed window, saat sınırında sıfırlanan bir sayaç. Çalıştırması en ucuz olanı — Redis’te expiry’li tek bir INCR — ama meşhur bir açığı var: kotanın tamamını sınırdan hemen önce, sonra hemen sonra tekrar ateşlersen API saniyenin bir kesrinde limitin iki katını görür. Sınır açığı botunu seç; fixed tarafın tepe değeri 2 kata çıkarken diğer ikisi reddediyor. Sliding window son timestamp’lerin kaydını tutuyor (production’da genelde ağırlıklı iki sayaç), yani kandırılacak bir sınır yok.

API’lerin çoğu neden token bucket seçer

Token bucket sabit hızda doluyor ve client’ın biriktirdiği token’ları bir anda harcamasına izin veriyor; sessiz bir dönemden sonra gelen kısa burst’ler bucket boyutu kadar geçiyor, uzun vadeli hız ise sınırda kalıyor. Bu, gerçek client’ların davranışına uyuyor: bir sayfa yüklemesi, bir retry fırtınası, önce planlayıp sonra harekete geçen bir agent. Bucket boyutunu 1’e indirirsen katı bir hız ayarlayıcıya dönüşür; büyütürsen daha affedici olur.

Simülasyon ve production

Buradaki her şey tarayıcında tek bir saatle çalışıyor, bu yüzden üç limiter kusursuz tutarlı. Gerçek bir kurulumda sayaç birçok gateway replica’sının paylaştığı bir store’da yaşar ve kendi trade-off’larını getirir: race’lerden kaçınmak için atomik Lua script’leri ya da sliding window sayaçları, Redis’i yormamak için lokal ön-limitler ve düzgün client’ların üstüne gitmek yerine geri çekilmesi için Retry-After / RateLimit header’ları.