[13] System Design - Проектируем свой Rate Limiter

Rate Limiter — это система, единственная задача которой сказать «нет». При этом сама она должна держать 1 000 000 RPS, отвечать быстрее 10 миллисекунд и никогда не падать. Разбираем, как такое проектируется: от алгоритмов до продакшн-системы на 100 миллионов пользователей в день. В этом видео: — Fail-open или fail-closed: что делать, когда лёг сам rate limiter? — 4 алгоритма: Fixed Window, Sliding Window Log и Counter, Token Bucket — Почему в реальных системах побеждает Token Bucket, а Sliding Window Log не выживает — Где живёт лимитер: библиотека, отдельный сервис, API Gateway или sidecar? — Расчёты: 3 миллиона операций в секунду, 100 ГБ счётчиков, 10 шардов Redis — Атомарность через Lua: почему нельзя сначала прочитать, а потом записать? — Батчинг, который экономит больше ресурсов, чем шардирование — Горячие ключи и шумный сосед: как один клиент кладёт целый шард — Динамические правила без похода в базу на горячем пути ━━━ Таймкоды ━━━ 00:00 Введение 00:33 Требования 02:25 Вопросы, которые надо решить до проектирования 07:13 Корневые сущности 10:09 Технические расчеты 15:23 Высокоуровневая архитектура 24:57 Четыре алгоритма Rate Limiting 34:00 Deep Dive — Масштабирование до 1M RPS 38:36 Deep Dive — Высокая доступность 40:44 Deep Dive — Минимизация задержек 42:48 Deep Dive — Горячие ключи и шумный сосед 45:25 Deep Dive — Динамические правила ━━━━━━━━━━━━ #systemdesign #systemdesigninterview #ratelimiter #backend #архитектура