ב-2013, Evernote קיבלה DDoS attack. אבל ה-attack לא בא מ-botnet חיצוני - הוא בא מ-mobile app שלהם עצמם. Bug ב-app גרם לכל ה-mobile clients (מיליונים) ל-reconnect כל 30 שניות. זה exponential retry without backoff. תוך שעה - מיליוני clients כל אחד שולח request כל 30 שניות. Rate Limiting שהיה אמור להיות שם - לא היה. ה-API קרס.
Rate Limiting הוא המנגנון שמגביל כמה requests client אחד יכול לשלוח ביחידת זמן. לא רק ל-hacker עם botnet - גם ל-app שלכם שכותב bug.
ב-2020, Zoom גדלה מ-10 מיליון ל-300 מיליון daily meeting participants בחודשיים. בלי rate limiting תקין, כל ישיבה חדשה יכלה ל-generate עשרות API calls ל-signaling servers. הם מיגרו ל-rate limiting אגרסיבי ב-edge - per-IP, per-user, per-tenant - כדי לשרוד את ה-growth הזה. Rate limiting אפשר להם ל-scale את ה-infrastructure בצורה נשלטת במקום ל-calibrate כל שירות בנפרד.
הסיפור של Evernote הוא classic self-DDoS - pattern שחוזר שוב ושוב ב-history. ב-2015, Slack גרמה ל-self-DDoS עצמה כש-bug ב-mobile app גרם ל-reconnection loop. ב-2018, Instagram ראתה spike של פי 10 ב-traffic כש-bug ב-app שלהם גרם ל-client ל-refetch את כל ה-timeline כל 2 שניות. בכל אחד מהמקרים האלה, Rate Limiting לא היה קיים או לא מספיק aggressive. Rate Limiting הוא לא רק להגן ממתקפות - הוא גם protection from yourself.
שימו לב ל-pattern בכל ה-disasters האלה: retry without backoff. Mobile app מקבל error (server busy, network timeout) ומיד retry. כל ה-clients עושים זאת בו-זמנית כי כולם יצאו מאותו release. כש-server חזר לחיים אחרי downtime, כל ה-retry requests הגיעו בו-זמנית - amplifying the original problem. Exponential backoff with jitter (שנראה בהמשך השיעור) הוא הפתרון.