Rate limiting שלא נעשה נכון = לקוחות טובים חוסמים. עברנו על 3 מודלים – הנה מה שעובד.

למה בכלל Rate Limiting

Protection: מונע DDoS, brute force attacks.

Fairness: משתמש אחד לא יכול לתפוס resources של כולם.

Cost control: אם יש paid APIs מאחורי, מונע bill shock.

SLA: מבטיח quality of service.

Token Bucket – הקלאסי

מודל: כל user יש ‘דלי’ של tokens. כל בקשה = -1 token. אם 0 = חסום.

Refill: X tokens לכל דקה.

יתרונות: מאפשר bursts. פשוט להבנה.

חסרונות: state management לכל user. מסובך בdistributed system.

Sliding Window – יותר מדויק

מודל: נספר בקשות בחלון זמן זז (5 minutes back from now).

יתרונות: מדויק יותר. פחות false positives.

חסרונות: יותר memory. יותר compute.

Fixed Window – הפשוט

מודל: 100 בקשות ב-hour מסוים. נמנה יורד ל-0 בכל hour.

יתרונות: פשוט. Cheap.

חסרונות: burst בסוף חלון + התחלה של חלון = 200 בקשות ב-2 דקות.

המימוש שלנו – Redis + Lua

Redis: מהיר. Distributed. Persistent.

Lua script: מבצע check + increment atomic – אין race conditions.

Example: SETNX + EXPIRE for fixed window. Sorted sets for sliding window.

איך להגדיר Limits

Anonymous users: נמוך מאוד (10/hour).

Free tier: 100/hour, 1000/day.

Paid tier: 10K/hour. Custom for enterprise.

API keys יש להם limits משלהם.

Error Responses

HTTP 429 Too Many Requests.

Response headers: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset (unix timestamp).

Body: JSON עם message ברור.

Gradient Rate Limiting

במקום 429 חד, האטו את התגובות בהדרגה. 100/hour = ok. 200/hour = 100ms delay per request. 500/hour = 500ms delay. 1000/hour = 429.

יותר forgiving. Bots ירדו לבד. Real users נשארים.

Whitelist

Internal services, monitoring, staff – במקום rate limit אחר.

IP-based או API-key-based whitelist.

מבוסס על פרויקטים אמיתיים

המדריך הזה מבוסס על עבודה עם:

• Platforma365

קריאה נוספת

אם המדריך הזה עזר לכם, אולי תרצו לקרוא גם על פיתוח SaaS מותאם – המדריך המקיף שלנו לתחום.