The post has been translated automatically. Original language: Russian
The request frequency limit usually appears in a hurry, after the first time when one customer posted the service. They take a round threshold, apply it to everyone, and after a week they deal with the complaints of those who are not to blame for anything.
Where they make mistakes when setting up
- The threshold is selected without data. No one has looked at the actual distribution of requests, so the limit either fails or cuts off normal work.
- The restriction applies to the address, not the client. One corporate client behind a shared address blocks the rest of the employees.
- One limit for all methods. Cheap reading and a heavy report cost differently, but they have the same quota.
- There is no useful information in the response. The client gets rejected and does not know how long to wait, so repeats immediately.
- Internal calls fall under the same limit. Own services are falling off, not external clients.
What to do
- Count the threshold from the actual load. Take a high percentile of regular traffic and leave a margin.
- Limit by client ID or access key. The address is the last option when there is nothing else.
- Divide the limits by the cost of operations. Heavy requests have a separate and smaller quota.
- In the rejection response, specify the time until the next attempt. This reduces the number of pointless repetitions more than any persuasion.
- First, turn on the monitoring mode. Count the exceedances without blocking and see who would have gone under the knife.
- Allow short bursts. A minute limit with a one-second burst tolerance cuts off the attack, but does not interfere with normal operation.
Result
Limiting the frequency of requests protects not only the service, but also the clients from each other. It works when the threshold is justified by the data, linked to the client and explains to him what to do next. Otherwise, it's just a way to turn an overload into a flood of support calls.
Do you roll out new limits in the monitoring mode or turn on the lock immediately?
Документацию принято считать делом второстепенным. Сначала мы делаем продукт, потом когда-нибудь описываем его. На практике всё наоборот: описание влияет на скорость работы команды сильнее, чем кажется.
Представьте нового разработчика в первую неделю. Он открывает проект и задаёт простые вопросы. Как запустить сервис у себя. Какие сервисы есть в системе и за что каждый отвечает. Куда идут данные после того, как пользователь нажал кнопку. Если ответы есть в тексте, человек начинает приносить пользу через несколько дней. Если ответов нет, он получает их через коллег, и каждый ответ отнимает время у двоих.
Второй пример ближе к продукту. Аналитик считает показатель и хочет понять, как он устроен. Если определение записано словами, а не только формулой, разговор занимает пять минут. Если определения нет, каждый считает по-своему, и потом команда сверяет две выгрузки вместо обсуждения решения.
Хорошая документация не бывает большой. Она отвечает на конкретные вопросы, которые люди задают чаще всего. Полезнее всего оказываются четыре вещи: короткое описание, зачем нужен сервис, инструкция по локальному запуску, схема связей между частями системы и список основных понятий с определениями.
Помогает простое правило. Текст пишет тот, кто делает задачу, и делает это в тот же момент, а не через месяц. Пока контекст в голове, описание занимает пятнадцать минут. Позже на то же самое уходит полдня, потому что детали приходится восстанавливать по коду.
Ещё одно правило про место. Описание живёт рядом с тем, что описывает, и обновляется вместе с ним. Текст в отдельном хранилище, к которому никто не возвращается, устаревает быстро и начинает вводить в заблуждение.
Проверить полезность текста можно за один шаг. Дайте его человеку, который не участвовал в разработке, и попросите выполнить описанное. Все места, где он остановился и спросил, и есть настоящий список того, что стоит дописать.
Документация это не отчёт для руководства и не формальность при сдаче задачи. Это способ сохранить знание команды в доступном виде, чтобы оно не жило только в переписке и в памяти отдельных людей.
А в вашей команде описание пишется вместе с задачей или отдельным этапом в конце?
Share
