Проверяет понимание проектирования состояния, тестируемости и конкуренции.
Глобальное состояние сложно тестировать, оно приводит к гонкам и не масштабируется между инстансами сервиса. Лучше хранить состояние в структурах с явной зависимостью и синхронизацией или во внешних хранилищах.
Глобальные переменные создают проблемы:
Data race
Несколько горутин читают/пишут в глобал → гонки и паники.
Тесты становятся нестабильными
Тесты влияют друг на друга, нужно чистить состояние.
Неявные зависимости
Код сложно читать: непонятно, кто меняет состояние.
Плохая масштабируемость
При нескольких экземплярах сервиса состояние будет разным.
Правильные подходы:
инкапсулировать состояние в структуре и передавать зависимости явно;
использовать sync.Mutex/RWMutex при необходимости;
для shared state — Redis/Postgres.
Вывод: глобальное состояние допустимо редко (конфиг/логгер), а бизнес-состояние лучше держать явно.
