Rate limiting اس بات کو محدود کرتا ہے کہ ایک client ایک وقت کی کھڑکی میں کتنی requests بھیج سکتا ہے۔ آپ اسے متعدد layers پر لاگو کرتے ہیں کیونکہ ہر ایک کچھ مختلف دیکھتا ہے، اور آپ اسے جو کچھ بھی abuser کی نشاندہی کرتا ہے اس سے key کرتے ہیں۔
Rate limiting اس بات کو محدود کرتا ہے کہ ایک client ایک وقت کی کھڑکی میں کتنی requests بھیج سکتا ہے۔ آپ اسے متعدد layers پر لاگو کرتے ہیں کیونکہ ہر ایک کچھ مختلف دیکھتا ہے، اور آپ اسے جو کچھ بھی abuser کی نشاندہی کرتا ہے اس سے key کرتے ہیں۔
429 Too Many Requests کو Retry-After کے ساتھ واپس کریں تاکہ clients خوشخواری سے پیچھے ہٹ جائیں بجائے ہتھوڑے مارنے کے۔# Define a shared-memory zone keyed by client IP.
# rate=10r/s = the steady refill rate (token bucket).
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
# burst=20: allow a short spike of 20 queued requests
# nodelay: serve the burst immediately instead of spacing it out
limit_req zone=api burst=20 nodelay;
# Return 429 (not the default 503) so clients see a rate-limit signal
limit_req_status 429;
proxy_pass http://backend;
}
}
یہاں ہر IP 10 requests/second پر دوبارہ بھرتا ہے، 20 تک burst کر سکتا ہے، اور اس سے آگے کی کوئی بھی چیز 429 ملتی ہے۔
Rate limiting آپ کا Layer 7 سیلابوں، credential stuffing، اور runaway scrapers کے خلاف سب سے سستا، ہمیشہ چالو دفاع ہے۔ اسے layering کرنا (حجم کے لیے edge، origin کے لیے proxy، business logic کے لیے app) اور اسے صحیح طریقے سے key کرنا abusers کو روکتا ہے جبکہ اصل users — اور legitimate bursts — بغیر رکے گزرتے ہیں۔ اصل baselines سے limits سیٹ کرنا ہی وہ ہے جو اسے آپ کی اپنی طرف سے ایک outage میں بدلنے سے روکتا ہے۔
تفصیلی جوابات کے ساتھ IT انٹرویو سوالات کی ایک لائبریری — جونیئر سے سینئر تک۔
عطیہ دیں