API Rate Limiting & Scalability Patterns · Ders

Redis ile Dağıtık Hız Sınırlama

Yarış koşullarını önlemek için Redis, atomik işlemler ve Lua betikleri kullanarak hız sınırı durumunu birden çok ağ geçidi ve hizmet örneği arasında paylaşmayı öğrenin.

Redis ile Dağıtık Hız Sınırlama, CoddyKit'te ücretsiz bir API Rate Limiting & Scalability Patterns dersidir. Bu, 4 dersinin 4. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, API Rate Limiting & Scalability Patterns öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. API Rate Limiting & Scalability Patterns kursu toplamda 4 dersten oluşur.

Bu dersin bazı bölümleri henüz çevrilmemiş olup İngilizce olarak gösterilmektedir.

The Multi-Instance Problem

When you run several gateway replicas, each one keeping its own in-memory counter means a client gets N x limit total — once per instance.

To enforce one global limit, every instance must read and update shared state.

Why Redis

Redis is the de facto choice for distributed rate limiting because it offers:

Sub-millisecond in-memory reads and writes
Atomic commands like INCR
Built-in expiry for automatic window resets
Lua scripting for multi-step atomic logic

A Naive Counter

The simplest fixed-window counter uses INCR plus EXPIRE:

The first request in a window creates the key and sets a TTL; later requests just increment.

INCR rate:user:42
-- if reply == 1 (first hit):
EXPIRE rate:user:42 60

The Race Condition

Running INCR then EXPIRE as two separate calls has a bug: if the process crashes between them, the key has no TTL and the limit never resets.

The fix is to make the check-and-increment atomic.

Atomicity with Lua

Redis runs a Lua script as a single atomic unit. We can check the count, increment, and set expiry without interruption.

local c = redis.call('INCR', KEYS[1])
if c == 1 then
  redis.call('EXPIRE', KEYS[1], ARGV[2])
end
if c > tonumber(ARGV[1]) then
  return 0
end
return 1

Calling the Script

From the gateway you invoke the script with EVAL, passing the key, the limit, and the window size.

A return of 1 means allow; 0 means reject with 429 Too Many Requests.

allowed = redis.eval(script, keys=['rate:user:42'], args=[100, 60])
if allowed == 0:
    return Response(status=429)

Sliding Window with Sorted Sets

For smoother limiting, store request timestamps in a sorted set. Remove old entries, count what remains, then add the new one.

ZREMRANGEBYSCORE rate:user:42 0 (now-window)
ZCARD rate:user:42
ZADD rate:user:42 now now

Returning Rate Limit Headers

Good gateways tell clients where they stand using standard headers:

X-RateLimit-Limit
X-RateLimit-Remaining
Retry-After on a 429

The Lua script can return remaining count alongside the allow flag.

Handling Redis Failures

What if Redis is unreachable? Two strategies:

Fail open — allow traffic; favors availability
Fail closed — reject traffic; favors protection

Most APIs fail open with a local fallback limiter to avoid a full outage.

Reducing Latency

Every limit check is a network hop. Cut overhead by:

Co-locating Redis near the gateway
Using connection pooling
Batching counters with a short local cache for very hot keys

Keying by Identity

The rate limit key defines what you are limiting. Common choices:

rate:ip:1.2.3.4 for anonymous traffic
rate:user:42 for authenticated users
rate:apikey:abc for API clients

Pick the most specific identity available so one abuser cannot exhaust a shared bucket.

Quick Check

Test your grasp of distributed limiting.

Recap

You learned to share rate limit state across instances:

A shared Redis store gives one global limit
Lua scripts make check-and-increment atomic
Sorted sets enable sliding windows
Decide fail open vs. closed for Redis outages

Sıkça Sorulan Sorular

“Redis ile Dağıtık Hız Sınırlama” dersi ücretsiz mi?

Evet — “Redis ile Dağıtık Hız Sınırlama” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve API Rate Limiting & Scalability Patterns kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. API Rate Limiting & Scalability Patterns kursu toplamda 4 dersten oluşur.

“Redis ile Dağıtık Hız Sınırlama” dersinde ne öğreneceğim?

Yarış koşullarını önlemek için Redis, atomik işlemler ve Lua betikleri kullanarak hız sınırı durumunu birden çok ağ geçidi ve hizmet örneği arasında paylaşmayı öğrenin. API Rate Limiting & Scalability Patterns ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

API Rate Limiting & Scalability Patterns öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te API Rate Limiting & Scalability Patterns, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 4. dersidir.

“Redis ile Dağıtık Hız Sınırlama” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu API Rate Limiting & Scalability Patterns dersinde kod yazıp çalıştırabilir miyim?

Evet. Her API Rate Limiting & Scalability Patterns dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

← API Rate Limiting & Scalability Patterns Sayfasına Dön