Есть ли у вас сильно нагруженные части системы

Что проверяют

Работали ли вы с нагрузкой на самом деле и можете ли говорить о ней цифрами: сколько запросов, какие задержки, где было узкое место и как вы это доказали. Следом почти всегда спрашивают, как вы нашли проблему и чем измеряли результат.

Как отвечать

Возьмите один компонент и расскажите по схеме, со своими числами:

• масштаб: RPS в среднем и в пике, p95 и p99 задержки, объём данных, число инстансов. Помните, что «10 тысяч в минуту» это меньше 200 запросов в секунду, для Go-сервиса это немного;
• узкое место и как нашли: pprof по CPU, памяти и блокировкам, go tool trace, гистограммы задержек в Prometheus, EXPLAIN ANALYZE для медленных запросов к базе;
• что сделали: пул воркеров вместо неограниченной горутины на каждую задачу, батчинг записи в базу или Kafka, настройка пула соединений (pgxpool или SetMaxOpenConns в database/sql), кэш с понятной инвалидацией, меньше аллокаций через sync.Pool и переиспользование буферов, rate limiting и backpressure на входе;
• рантайм: GOMEMLIMIT против OOM в контейнере и GOMAXPROCS по квоте CPU, начиная с Go 1.25 рантайм учитывает лимит cgroup сам;
• результат: было и стало в тех же метриках и как проверяли, нагрузочным тестом (k6, vegeta) или на проде.

Если по-настоящему нагруженных частей не было, скажите честно. Расскажите о самом нагруженном месте, которое было, пусть это сотня RPS, и о том, как масштабировали бы его в десять раз. Это ценнее придуманных миллионов.

Где спотыкаются

Называют средние задержки вместо перцентилей. Среднее прячет хвост, из-за которого и приходят жалобы.

Говорят «добавили кэш, стало быстрее» и не могут объяснить, как кэш инвалидируется и что происходит при холодном старте.

Рассказывают об оптимизации без замеров до и после. Без профиля это догадка, и интервьюер это услышит.