AdaYilmaz
Backend & API
Merhaba arkadaşlar, son birkaç projede rate limiting tarafını yeniden kurguladığım için deneyimlerimi paylaşmak istedim. Özellikle dışarıya açık API'lerde hem kötüye kullanımı engellemek hem de altyapıyı korumak için bunu doğru yapmak şart. Aşağıda benim izlediğim yol ve dikkat ettiğim noktalar var.
1. Önce limit türünü netleştirin
Her endpoint aynı limiti hak etmiyor. Login, şifre sıfırlama gibi hassas uçlara çok daha sıkı limit koyun; salt okuma uçlarına daha geniş. Kullanıcı bazlı, IP bazlı ve API key bazlı limitleri ayrı ayrı düşünün.
2. Algoritma seçimi
Sabit pencere (fixed window) basit ama sınır anlarında ani patlamalara izin verir. Kayan pencere (sliding window) daha adil. Token bucket ise burst trafiği tolere etmek için bence en pratik seçenek. Ben genelde Redis üzerinde token bucket tercih ediyorum.
3. Sayaçları nerede tutacaksınız?
Çok instance'lı bir kurulumda bellek içi sayaç işe yaramaz. Redis veya benzeri merkezi bir store kullanın. Lua script ile atomik artırma yapmak, yarış koşullarını (race condition) engellemenin en temiz yolu.
4. Standart header'ları döndürün
İstemcilerin ne zaman beklemesi gerektiğini bilmesi lazım. X-RateLimit-Limit, X-RateLimit-Remaining ve Retry-After header'larını döndürün. Limit aşılınca 429 dönmek doğru davranış; 403 dönmek yanlış sinyal veriyor.
5. Geri baskı ve maliyet
Sadece istek sayısını saymak yetmez. Pahalı işlemleri (rapor üretimi, toplu sorgu) ağırlıklı limitlere bağlayın. Bir istek 10 birim, diğeri 1 birim tüketsin gibi.
6. İzleme ve ayar
Limitleri koyup unutmayın. Metrik toplayın: 429 oranı, en çok limit aşan IP'ler, endpoint bazlı dağılım. Bu veriler limitleri gerçek kullanıma göre ayarlamanızı sağlar.
7. Test etmeyi unutmayın
Yük testinde limitin gerçekten devreye girdiğini ve dağıtık ortamda tutarlı çalıştığını doğrulayın. Birden fazla instance açıp aynı kullanıcıyla paralel istek atın; sayaçların doğru arttığını görün.
Kısaca: merkezi store + atomik sayaç + doğru header'lar + izleme üçlüsü işin belkemiği. Gerisi ihtiyaca göre şekilleniyor.
Siz üretimde hangi algoritmayı kullanıyorsunuz? Redis dışında bir çözümle (örneğin gateway seviyesinde) tecrübesi olan var mı? Özellikle çok kiracılı (multi-tenant) yapılarda limitleri nasıl ayırıyorsunuz, bunu merak ediyorum.
1. Önce limit türünü netleştirin
Her endpoint aynı limiti hak etmiyor. Login, şifre sıfırlama gibi hassas uçlara çok daha sıkı limit koyun; salt okuma uçlarına daha geniş. Kullanıcı bazlı, IP bazlı ve API key bazlı limitleri ayrı ayrı düşünün.
2. Algoritma seçimi
Sabit pencere (fixed window) basit ama sınır anlarında ani patlamalara izin verir. Kayan pencere (sliding window) daha adil. Token bucket ise burst trafiği tolere etmek için bence en pratik seçenek. Ben genelde Redis üzerinde token bucket tercih ediyorum.
3. Sayaçları nerede tutacaksınız?
Çok instance'lı bir kurulumda bellek içi sayaç işe yaramaz. Redis veya benzeri merkezi bir store kullanın. Lua script ile atomik artırma yapmak, yarış koşullarını (race condition) engellemenin en temiz yolu.
4. Standart header'ları döndürün
İstemcilerin ne zaman beklemesi gerektiğini bilmesi lazım. X-RateLimit-Limit, X-RateLimit-Remaining ve Retry-After header'larını döndürün. Limit aşılınca 429 dönmek doğru davranış; 403 dönmek yanlış sinyal veriyor.
5. Geri baskı ve maliyet
Sadece istek sayısını saymak yetmez. Pahalı işlemleri (rapor üretimi, toplu sorgu) ağırlıklı limitlere bağlayın. Bir istek 10 birim, diğeri 1 birim tüketsin gibi.
6. İzleme ve ayar
Limitleri koyup unutmayın. Metrik toplayın: 429 oranı, en çok limit aşan IP'ler, endpoint bazlı dağılım. Bu veriler limitleri gerçek kullanıma göre ayarlamanızı sağlar.
7. Test etmeyi unutmayın
Yük testinde limitin gerçekten devreye girdiğini ve dağıtık ortamda tutarlı çalıştığını doğrulayın. Birden fazla instance açıp aynı kullanıcıyla paralel istek atın; sayaçların doğru arttığını görün.
Kısaca: merkezi store + atomik sayaç + doğru header'lar + izleme üçlüsü işin belkemiği. Gerisi ihtiyaca göre şekilleniyor.
Siz üretimde hangi algoritmayı kullanıyorsunuz? Redis dışında bir çözümle (örneğin gateway seviyesinde) tecrübesi olan var mı? Özellikle çok kiracılı (multi-tenant) yapılarda limitleri nasıl ayırıyorsunuz, bunu merak ediyorum.