Были ли проблемы из-за нагрузки и приходилось ли оптимизировать

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

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

Как отвечать

Каркас рассказа: симптом, как нашли причину, что изменили, как проверили. Цифры берите свои: RPS, p99, память, число подов.

Инструменты, которые стоит назвать в контексте своего случая:

• pprof: net/http/pprof в сервисе и go tool pprof для CPU, heap, allocs, goroutine. Профили mutex и block сначала включают через runtime.SetMutexProfileFraction и runtime.SetBlockProfileRate;
• трасса: go tool trace показывает паузы GC, простой горутин, работу планировщика;
• бенчмарки: go test -bench . -benchmem, сравнение через benchstat, анализ побега в кучу через go build -gcflags=-m;
• нагрузочный тест: k6, vegeta или wrk до и после изменения.

Типичные находки в Go-сервисах: лишние аллокации в горячем цикле (помогают предвыделение слайсов и sync.Pool), борьба за один мьютекс, утечки горутин без отмены через context, исчерпание пула database/sql (SetMaxOpenConns, SetConnMaxIdleTime), N+1 запросы к базе. Для памяти есть GOMEMLIMIT. В контейнерах важен GOMAXPROCS: начиная с Go 1.25 рантайм сам учитывает лимит CPU из cgroup, в старых версиях ставили automaxprocs.

Если высоких нагрузок не было, скажите честно и покажите тот же подход на бенчмарке или учебном сервисе.

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

Начинают с «переписали на горутины» или «добавили кэш» без профиля. Интервьюер спросит, откуда было известно, что тормозит именно это.

Называют круглые проценты вроде «ускорили на 50%», не объясняя, какую метрику и при какой нагрузке мерили. Средняя задержка без p99 почти ничего не говорит.

Масштабируют горизонтально, не проверив общий ресурс. Десять подов, упёршихся в одну базу, быстрее не станут, а соединения в ней закончатся ещё раньше.