🛡 Rate Limiting, часть 2: как это красиво прикрутить в ASP.NET Core

Окей, в первой части разобрались какие алгоритмы бывают. Теперь самое вкусное — как это всё настроить так, чтобы было не стыдно показать на код-ревью.

В Microsoft.AspNetCore.RateLimiting всё уже есть из коробки. Самый базовый вариант — создаёшь именованную политику и вешаешь на эндпоинт (за примером проследуйте на пояснительный дикпик 1).

Можно сделать и глобальный лимитер на всё приложение, но чаще нужны именованные политики — разные лимиты для разных эндпоинтов. А ещё есть PartitionedRateLimiter — он создаёт отдельное ведро токенов для каждого пользователя (дикпик 2). Один энтузиаст с циклом не мешает остальным.

К примеру, для моего API базы знаний план может быть такой:

1️⃣ эндпоинт article/smart-search, который дёргает LLM — жёсткий Token Bucket, 20 запросов в час на юзера.

2️⃣ Остальные эндпоинты — мягкий Fixed Window на 100 запросов в минуту. Health-чек — без лимитов, чтобы кубер не страдал. Всё это настраивается через именованные политики и атрибут EnableRateLimiting на контроллере (дикпик 3).

Ещё прикольный момент вычитал — как думаете, что возвращать когда лимит превышен?

Ответ: По дефолту просто 429, но можно красиво: клиент получает заголовок Retry-After с количеством секунд до следующей попытки 🕜. Вежливо и по стандарту (дикпик 4).

Любой зоркий глаз, дочитавший до этого момента думаю задается вопросом, а как все эти рейт-лимиты работают между несколькими экземплярами приложения?

Об этом в следующей части. А пока спойлер: встроенный rate limiter считает in-memory, и каждый под живёт своей жизнью…

📦 Кстати, не пояснительными дикпиками едиными! 🍆 Вот пояснительный пример с кодом: https://github.com/Undermove/csharpshortpostsexamples/tree/main/RateLimitingExample

#csharp #ratelimiting