Ещё одна важная вещь, которую нужно продумать при интеграциях – это rate limiting.

По моим наблюдениям сейчас это уже стандартная практика – прописывать rate limiting заранее, а вот раньше об этом вспоминали в момент, когда интеграция начинала отправлять сотни запросов в секунду, и система неожиданно падала.

Rate limiting – это механизм ограничения количества запросов за определённый период времени. Он защищает систему от перегрузок, ошибок в интеграциях и резких всплесков трафика.
Такие вещи лучше продумывать сразу на этапе требований.

Когда я описываю интеграцию, я всегда стараюсь заранее определить лимиты запросов.

Например:
◾️сколько запросов допустимо в минуту
◾️применяется ли лимит к пользователю, API-ключу или IP
◾️действует ли он на конкретный метод или на весь сервис
То есть так и пишу «Не более 100 запросов в минуту на API-ключ».

Но лимиты – это только часть истории. Следующий вопрос, который я обычно описываю: что происходит, если лимит превышен.

Чаще всего возвращается HTTP-код 429 (Too Many Requests) и сообщение о превышении ограничения.
Иногда также добавляю информацию о том, когда можно повторить запрос.

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

Поэтому я обычно фиксирую:
◾️можно ли делать повторный запрос
◾️через какой интервал
◾️сколько попыток допустимо

Также важно понимать критичность операций.

Одни запросы можно спокойно отклонить при превышении лимита, а другие лучше поставить в очередь и обработать позже. Это тоже стоит обозначить в требованиях.

Здесь так же, как и с webhooks, описание правил на нас – системных аналитиках, а разработчик реализует техническую часть.

🔥 если полезно и хотите больше технических постов