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
«Share memory by communicating» — это рекомендация, а не догма. Каналы хороши, когда вы **передаёте владение данными** между горутинами или координируете поток событий/жизненный цикл; мьютекс/atomic хороши, когда вы **защищаете разделяемое состояние** при коротких операциях. Канал внутри — это структура с мьютексом и очередью, так что он не «бесплатнее» мьютекса. Критерий простой: владение/передача/оркестрация → канал; разделяемое состояние/кэш/счётчик → мьютекс/atomic.

## Теория

### Два девиза Go
- **«Don't communicate by sharing memory; share memory by communicating.»** — каналы как основной способ координации.
- **Контр-цитата команды Go:** *«Use whichever is most expressive and/or most simple.»* (Go wiki). Каналы — не самоцель.

### Что такое канал на самом деле
Канал (`hchan`) — это **структура с мьютексом** (`lock`), кольцевым буфером, очередями `sendq`/`recvq` парковки горутин. То есть канал реализован поверх блокировок и семафоров рантайма. Поэтому:
- канал **не дешевле** мьютекса для простой защиты переменной — наоборот, обычно дороже (больше работы: блокировка, копирование значения, парковка/побудка);
- «канал = безопасность» — миф; неправильное использование канала даёт дедлоки и утечки не хуже мьютекса.

### Когда КАНАЛ
1. **Передача владения данными.** Горутина-производитель отдаёт значение и больше его не трогает — получатель становится единственным владельцем. Нет shared state → нет гонок по построению.
   ```go
   jobs := make(chan Job)
   go func() { for j := range jobs { process(j) } }() // владелец j — обработчик
   jobs <- job
   ```
2. **Оркестрация / поток событий.** Pipeline, fan-in/fan-out, сигналы (done/cancel), таймауты через select. Каналы интегрируются с `select` и `context`.
3. **Сигнал «событие произошло».** `close(done)` как broadcast; буфер для развязки producer/consumer.
4. **Распределение работы.** Worker pool: один канал задач, N воркеров.

### Когда MUTEX (или atomic)
1. **Защита разделяемого состояния** с короткими операциями: счётчики, кэши, мапы, конфиг.
   ```go
   type Cache struct { mu sync.Mutex; m map[string]V }
   func (c *Cache) Get(k string) V { c.mu.Lock(); defer c.mu.Unlock(); return c.m[k] }
   ```
2. **Составной инвариант** над несколькими полями структуры (atomic не умеет).
3. **Горячий путь, где важна латентность/throughput** простой защиты — мьютекс с быстрым CAS-путём дешевле канала.
4. **Кэш/реестр/пул**, где «состояние» естественно живёт в одном месте, а не «течёт» между горутинами.

### Сравнительная таблица
| Критерий | Канал | Mutex/atomic |
|---|---|---|
| Парадигма | передача владения, коммуникация | защита общего состояния |
| Интеграция с select/ctx/таймаут | да | нет |
| Передача данных | да | нет (только защита) |
| Broadcast события | да (`close`) | нет (нужен Cond) |
| Стоимость простой защиты | выше | ниже (CAS быстрый путь) |
| Составной инвариант | неудобно | да |
| Риск дедлока/утечки | да (забытая ветка) | да (забытый Unlock) |
| Backpressure | да (буфер/блокировка) | нет |

### Критерии выбора (чек-лист)
- Данные **перемещаются** от одной горутины к другой → канал.
- Данные **остаются на месте**, доступ конкурентный → мьютекс/atomic.
- Нужен таймаут/отмена/выбор из нескольких источников → канал + select.
- Нужен счётчик/флаг/один указатель → atomic.
- Нужно ограничить число одновременных операций → канал-семафор (`chan struct{}` ёмкости N).
- Нужно broadcast всем «стоп» → `close(done)`.
- Высокая частота, простая операция, важна латентность → мьютекс/atomic.

## Подводные камни / gotchas
- **«Каналы всегда безопаснее/быстрее» — неверно.** Канал — это мьютекс + очередь + копирование. Для защиты счётчика канал избыточен и медленнее atomic.
- **Один разделяемый объект «спрятать» за каналом** (актор-горутина, владеющая состоянием) — валидный паттерн, но добавляет горутину, латентность и точку отказа. Иногда мьютекс проще.
- **Смешение подходов в одном месте** (часть состояния через канал, часть через мьютекс на тех же данных) → путаница и гонки. Выберите одну модель владения на единицу данных.
- **Мапа под мьютексом vs sync.Map vs канал-актор:** для read-heavy — `atomic.Pointer` (COW) или sharded mutex; канал-актор сериализует доступ и может стать бутылочным горлышком.
- **Дедлок на небуферизованном канале** при отправке без готового получателя — частая ошибка «канальной» модели, аналог забытого Unlock в «мьютексной».

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

**В:** Канал или мьютекс — что выбрать и почему именно так формулируют критерий?
**О:** Если данные **передаются** между горутинами (меняется владелец) — канал: получатель становится единственным владельцем, гонок нет по построению. Если данные **разделяются** и доступ конкурентный (счётчик, кэш, инвариант) — мьютекс/atomic. Это и есть граница: коммуникация/владение vs защита состояния.

**В:** Правда ли, что каналы безопаснее и поэтому всегда предпочтительны?
**О:** Нет. Каналы дают другую модель (передача владения), которая для своих задач элегантна, но они так же подвержены дедлокам и утечкам. Сама команда Go советует выбирать наиболее простой и выразительный инструмент, а не каналы по умолчанию.

**В:** Дешевле ли канал, чем мьютекс?
**О:** Обычно нет. Канал внутри — структура с собственным мьютексом, кольцевым буфером и очередями парковки, плюс копирование значения. Для простой защиты переменной atomic/мьютекс быстрее. Канал оправдан коммуникацией, а не экономией.

**В:** Как защитить счётчик: канал или atomic?
**О:** `atomic.Int64`. Канал тут — оверкилл: больше аллокаций, парковок, копирований и латентности. Atomic.Add — одна аппаратная инструкция.

**В:** Когда канал явно лучше мьютекса?
**О:** Когда нужны: передача данных между горутинами, выбор из нескольких источников/таймаут/отмена (select+ctx), backpressure через буфер, broadcast «стоп» через close, распределение задач воркерам. Мьютекс этого не умеет.

**В:** Что такое «актор» на канале и его минусы?
**О:** Горутина — единоличный владелец состояния, остальные шлют ей запросы по каналу; она сериализует доступ. Плюс: нет блокировок у клиентов, чёткое владение. Минусы: лишняя горутина, латентность запрос-ответ, потенциальное бутылочное горлышко, сложнее отладка. Часто мьютекс проще.

**В:** Можно ли смешивать каналы и мьютексы?
**О:** В программе — да, для разных задач. Но для **одной единицы данных** выбирайте одну модель владения. Защищать одно и то же состояние частично каналом, частично мьютексом — путь к гонкам и путанице.

**В:** Как ограничить конкуренцию — каналом или мьютексом?
**О:** Каналом-семафором: `sem := make(chan struct{}, N)`; перед работой `sem <- struct{}{}`, после — `<-sem`. Это ограничивает N одновременных операций. Мьютекс даёт только N=1. Для N>1 — буферизованный канал или `golang.org/x/sync/semaphore`.

## На что копают на senior+
- Реализация `hchan`: канал как мьютекс+буфер+sendq/recvq; почему он не дешевле мьютекса.
- Передача владения как способ устранить гонки без блокировок (memory model: send happens-before recv).
- Актор-модель на горутине-владельце vs мьютекс vs atomic.Pointer COW: trade-offs по латентности, throughput, сложности.
- Backpressure и буферизация: как каналы дают управление потоком, чего мьютекс не умеет.
- Когнитивная стоимость: дедлоки канальной модели vs забытый Unlock; диагностика и того, и другого.
- Бенчмаркинг: почему «каналы медленнее» в микробенчах и когда это перестаёт иметь значение под реальной нагрузкой.