Работали ли вы с highload сервисами
Что проверяют
Что вы называете нагрузкой и умеете ли про неё говорить числами. А ещё, понимаете ли ограничения языка: где асинхронность спасает, а где упирается в глобальную блокировку интерпретатора.
Как отвечать
Начните с профиля нагрузки, иначе разговор превращается в перечисление технологий: сколько запросов в секунду, ровный поток или пики, размер ответа, доля записи, требования к задержке на хвосте и к доступности.
Дальше по слоям, от дешёвого к дорогому:
- измерение: профилирование, трассировка, метрики по эндпоинтам, нагрузочный прогон на стенде, а не на проде;
- база: почти всегда первая упирается. Индексы, лишние запросы в цикле, размер пула соединений, вынос чтения на реплики;
- кэш: что кэшируем, на какой срок, как инвалидируем и как не получить лавину запросов в момент истечения популярного ключа;
- асинхронность: помогает на задачах, ждущих ввода-вывода. Счётные задачи выносятся в отдельные процессы или сервисы;
- очереди: всё, что можно не делать внутри запроса, делается фоном;
- горизонталь: процессы без состояния, идемпотентные обработчики, ограничение частоты и осознанная деградация под пиком.
Где спотыкаются
Приносят красивые проценты прироста и падения задержки из шаблона. Дальше идут вопросы: чем нагружали, сколько длился прогон, что было узким местом до и после. История разваливается на втором уточнении, и доверие к остальному рассказу падает вместе с ней.
Второе: считают, что асинхронный фреймворк ускоряет всё подряд. Одна синхронная библиотека внутри обработчика блокирует цикл событий и кладёт весь рабочий процесс, а счётные задачи от перехода не выигрывают вовсе.
Третье: оптимизируют код, не посмотрев в базу и сеть. Переписывают цикл на списковое выражение, пока запрос без индекса читает таблицу целиком. Начинать надо с замера, а не с догадки о медленном месте.