Senior Go Interview Prep

- Core Go: https://go.vbloher.org/docs/01-core-go/
- Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/
- Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/
- Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/
- Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/
- Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/
- Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/
- panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/
- Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/
- Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/
- Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/
- Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/
- Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/
- Concurrency: https://go.vbloher.org/docs/02-concurrency/
- sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/
- Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/
- Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/
- Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/
- Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/
- sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/
- context: https://go.vbloher.org/docs/02-concurrency/context/
- Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/
- sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/
- sync.Once: https://go.vbloher.org/docs/02-concurrency/once/
- Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/
- Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/
- Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/
- select: https://go.vbloher.org/docs/02-concurrency/select/
- sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/
- Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/
- Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/
- Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/
- Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/
- Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/
- GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/
- Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/
- Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/
- Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/
- pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/
- Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/
- Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/
- Тестирование: https://go.vbloher.org/docs/04-testing/
- testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/
- Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/
- Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/
- Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/
- Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/
- Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/
- Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/
- Backend: https://go.vbloher.org/docs/05-backend/
- Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/
- Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/
- gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/
- JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/
- Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/
- net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/
- OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/
- OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/
- Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/
- REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/
- Сети и протоколы: https://go.vbloher.org/docs/06-networking/
- Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/
- DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/
- Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/
- TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/
- TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/
- UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/
- WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/
- Базы данных: https://go.vbloher.org/docs/07-databases/
- Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/
- Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/
- Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/
- Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/
- MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/
- Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/
- Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/
- Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/
- Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/
- Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/
- Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/
- Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/
- Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/
- CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/
- Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/
- Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/
- Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/
- Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/
- Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/
- Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/
- Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/
- Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/
- RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/
- Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/
- Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/
- Observability: https://go.vbloher.org/docs/09-observability/
- Grafana: https://go.vbloher.org/docs/09-observability/grafana/
- Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/
- OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/
- Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/
- SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/
- Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/
- Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/
- System Design: https://go.vbloher.org/docs/10-system-design/
- Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/
- Chat System: https://go.vbloher.org/docs/10-system-design/chat/
- Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/
- Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/
- Order Service: https://go.vbloher.org/docs/10-system-design/order-service/
- Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/
- Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/
- URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/
- DevOps: https://go.vbloher.org/docs/11-devops/
- CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/
- Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/
- Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/
- GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/
- Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/
- Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/
- Алгоритмы: https://go.vbloher.org/docs/12-algorithms/
- Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/
- Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/
- Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/
- Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/
- Behavioral: https://go.vbloher.org/docs/13-behavioral/
- Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/
- Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/
- Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/
- Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/


> Модуль: Concurrency · Уровень: Senior

## TL;DR
Гонка данных — это два конкурентных доступа к одной памяти, где хотя бы один — запись, и между ними нет отношения happens-before. В Go такое поведение **не определено**. Детектор гонок (`go test -race`, `go run -race`) построен на ThreadSanitizer: он динамически отслеживает happens-before через векторные часы и сообщает о реальных гонках, наблюдённых на конкретном прогоне. Цена высока (память ×5–10, скорость ×2–20), и он **не доказывает отсутствие гонок** — только находит те, что фактически случились.

## Теория

### Что такое гонка данных
Формально (по Go memory model) гонка — это:
1. два доступа к одной ячейке памяти из разных горутин,
2. хотя бы один из них — запись,
3. они не упорядочены отношением happens-before (нет синхронизации между ними).

Гонка ≠ просто «конкурентный доступ»: два чтения — не гонка; запись+чтение под общим мьютексом — не гонка (мьютекс создаёт happens-before). Важно: с Go 1.19 спецификация явно говорит, что программа с гонкой данных имеет **undefined behavior** — компилятор/железо вправе делать что угодно (разорванные значения, «невозможные» состояния).

### Happens-before — ядро модели
Отношение happens-before задаётся:
- внутри одной горутины — порядком программы;
- `go` statement happens-before начала горутины;
- send в канал happens-before завершения соответствующего receive; close happens-before receive нуля из закрытого канала;
- `Unlock` happens-before последующего `Lock`; release atomic happens-before acquire того же значения; `Done` happens-before возврата `Wait`; и т.д.

Если между двумя доступами нет цепочки happens-before — это гонка.

### Как работает детектор (ThreadSanitizer)
`-race` инструментирует код: компилятор вставляет вызовы в рантайм TSan на **каждый** доступ к памяти и на каждую синхронизирующую операцию.

- **Shadow memory.** Для каждого слова данных TSan хранит «теневые» записи о последних доступах: какая горутина, какой тип (read/write), значение векторных часов.
- **Vector clocks.** Каждая горутина и каждый синхро-объект (мьютекс, канал) несут векторные часы. Синхронизация (Unlock/Lock, send/recv) обновляет их, фиксируя happens-before.
- **Детекция.** При доступе TSan сравнивает текущие часы с теневыми: если есть предыдущий конфликтующий доступ из другой горутины, не упорядоченный happens-before, — это гонка, печатается стек обоих доступов.

Это **динамический** анализ: ловит только то, что реально выполнилось в данном прогоне с данным расписанием горутин.

```bash
go test -race ./...
go build -race -o app ./cmd/app   # для прод-нагрузочного теста (не для прода!)
go run -race main.go
```

Пример вывода:
```
==================
WARNING: DATA RACE
Write at 0x00c0000b4010 by goroutine 7:
  main.(*Counter).Inc()
      counter.go:12 +0x...
Previous read at 0x00c0000b4010 by goroutine 6:
  main.(*Counter).Value()
      counter.go:16 +0x...
==================
```

### Стоимость
- **Память:** ×5–10 (shadow memory).
- **CPU/время:** ×2–20 в зависимости от плотности доступов к памяти.
- Поэтому `-race` гоняют в CI/тестах и иногда на canary под реальной нагрузкой, **но не в обычном проде** массово. Только инструментированный бинарь видит гонки.

### Что детектор НЕ ловит
- **Гонки, которых не было в прогоне.** Не исполнили путь / расписание не совпало → не увидим. Поэтому нужны нагрузочные/стресс-тесты, разнообразные сценарии, `GOMAXPROCS>1`.
- **Логические гонки (race conditions), не являющиеся data race.** Например, check-then-act через каналы/atomic без нарушения happens-before на одной ячейке: `if exists { use }` где между проверкой и использованием состояние меняется — это логическая гонка, но не data race.
- **Гонки через `unsafe.Pointer`** в обход системы типов могут быть невидимы или искажены.
- **Гонки в неинструментированном коде:** ассемблер, cgo (частично), сторонние бинари.
- **Дедлоки/livelock/leaks** — это не его задача (дедлок всех горутин ловит рантайм-паника `all goroutines are asleep - deadlock!`, но только полный).
- **Неинициализированные данные / атомарность бизнес-инвариантов** — вне области.

## Подводные камни / gotchas
- **«Нет варнингов» ≠ «нет гонок».** Детектор не верификатор. Отсутствие находок означает только, что в этих прогонах гонок не наблюдалось.
- **Запускайте с реальным параллелизмом.** `GOMAXPROCS=1` или последовательные тесты прячут гонки. Гоняйте с `-race -count=N`, стресс-тестами, `t.Parallel()`.
- **Накладные расходы искажают тайминги** — гонка, видимая под `-race`, в обычном бинаре может «не воспроизводиться» (и наоборот). Это не значит, что её нет.
- **Только инструментированный бинарь.** Нельзя добавить `-race` к уже собранному обычному бинарю; нужна пересборка.
- **Глобальный лимит детектора:** TSan имеет лимит на число одновременно отслеживаемых синхро-объектов; в гигантских программах возможны пропуски.
- **`-race` меняет поведение по таймингам** — иногда маскирует/демаскирует другие баги (Heisenbug).

## Вопросы на собеседовании

**В:** Чем гонка данных отличается от race condition?
**О:** Data race — технический термин: неупорядоченные конкурентные доступы к одной памяти, где есть запись (UB по спеке). Race condition — более широкое понятие логической ошибки из-за порядка событий; она может существовать и без data race (например, check-then-act через корректно синхронизированные atomic). Детектор ловит первое, не второе.

**В:** Как работает `-race` под капотом?
**О:** Это ThreadSanitizer. Компилятор инструментирует каждый доступ к памяти и синхро-операцию. Рантайм ведёт shadow memory и векторные часы для горутин и синхро-объектов; при доступе сравнивает часы и, если находит конфликтующий доступ без happens-before, рапортует гонку со стеками.

**В:** Гарантирует ли чистый прогон `-race` отсутствие гонок?
**О:** Нет. Это динамический детектор: видит только гонки, реально случившиеся в данном расписании и пути исполнения. Нужны разнообразные сценарии, стресс, `GOMAXPROCS>1`, `-count`. Отсутствие находок — не доказательство.

**В:** Почему `-race` не включают в проде?
**О:** Память ×5–10, скорость ×2–20. Для большинства прод-нагрузок это неприемлемо. Используют в CI/тестах и иногда на ограниченном canary. Плюс нужен специально пересобранный инструментированный бинарь.

**В:** Что детектор НЕ находит?
**О:** Гонки, не воспроизведённые в прогоне; логические race condition без data race; дедлоки/livelock/утечки горутин; многое через unsafe/cgo/ассемблер. Это узкоспециализированный инструмент именно для data race.

**В:** Что такое happens-before и почему это центральное понятие?
**О:** Частичный порядок событий, задаваемый синхронизацией (go, каналы, мьютексы, atomic, WaitGroup). Если два конфликтующих доступа им упорядочены — гонки нет. Детектор именно проверяет наличие happens-before между доступами через векторные часы.

**В:** Как поймать гонку, которая редко воспроизводится?
**О:** Стресс-тесты с высоким параллелизмом (`GOMAXPROCS`>1), много итераций (`-count`, `-race`), фаззинг/рандомизация порядка, `t.Parallel()`, прогон на canary под реальной нагрузкой с инструментированным бинарём. Увеличение конкуренции повышает шанс наблюдения.

**В:** Что делает рантайм при «fatal error: all goroutines are asleep - deadlock»?
**О:** Это не детектор гонок, а отдельная проверка планировщика: если **все** горутины заблокированы и нет работы, рантайм паникует. Частичный дедлок (живёт хоть одна горутина) так не ловится.

## На что копают на senior+
- Формулировка Go memory model (особенно ужесточение 1.19: data race = UB, ранее «частично определено» для отдельных типов).
- Внутренности TSan: shadow cells (обычно 4 на слово), векторные часы, как канал/мьютекс переносят happens-before между горутинами.
- Почему два чтения — не гонка, а publish через atomic-флаг безопасен (release/acquire).
- Различие data race vs logical race на конкретных примерах (double-check, lost update).
- Стратегия тестирования конкурентности: детерминизм vs стресс, `-race` в CI, ограничения и Heisenbug-эффект.
- Что происходит на железе при гонке: разорванная запись 64-бит на 32-бит, переупорядочивание store/load, видимость кэшей.