System Design: проектируем Rate Limiter, ограничитель запросов

[gerbert_MX]

крутая статья, единое что - странный фокус на Редисе. Ограничители бывают самописными, а еще они бывают на базе брокеров в качестве шины-маршрутизатора

Ожидания "по уровням" спорное но это уже чисто ваше мнение и как в заключение, что никак не влияет на статью. В остальном же очень круто, разнопланово и по делу.

[enemigo]

огранчение сервиса по временным интервалам - это просто, но создает множество проблем, собственно, и описанных в данной статье. К тому же создается впечатление что вам жалко свободных ресурсов для случая единственного забредшего на огонек пользователя. Поэтому данная статья о том как не стоит делать. Наиболее эффективная система ограничений строится на мгновенных метриках, число in-flight запросов, например. Вот о такой я бы почитал.

[Void-Cowboy]

да нет, в статье описано классическое отсечение для систем АПИ и тому подобное, когда пользователю выдаются доступы в жестких рамках, вплоть до лимитов на минуту/час/сутки

защита от перегруза это иное вообще и там действительно в потоке смотрят, а не по уникализации. И как раз таки защита от перегруза может строится на базе внешних мгновенных метрик по типу "сколько активных ключей в редисе"

[Sega-mobile]

Было интересно. Но не вникать в тонкости, описанные в статье (не мой уровень), а было интересно увидеть rate limiter в роли стабилизатора нагрузки на сервер.

В моем pet-project rate limiter выполняет защитную функцию и устроен очень примитивно (по сравнению с примерами из статьи) - если от одного пользователя поступило больше 30 запросов меньше чем за 5 минут: бан на 4 часа. (Кому интересно - ви-за-ви.рф).

Интересно, какие ещё роли может выполнять этот механизм..?