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 · Уровень: Middle+/Senior

## TL;DR
`sync.Once` гарантирует, что переданная функция выполнится **ровно один раз** за всё время жизни, даже при конкурентных вызовах из множества горутин — основа для потокобезопасной ленивой инициализации. Внутри — атомарный флаг (быстрый путь без блокировки) плюс мьютекс для медленного пути. Go 1.21 добавил эргономичные обёртки `OnceFunc`, `OnceValue`, `OnceValues`.

## Теория

### Контракт
```go
var once sync.Once
var conn *DB

func GetDB() *DB {
    once.Do(func() {
        conn = connect() // выполнится ровно один раз
    })
    return conn
}
```
- `Do(f)` вызывает `f` только при **первом** вызове. Все остальные вызовы (включая конкурентные) **блокируются**, пока первый `f` не завершится, и только потом возвращаются.
- Гарантия видимости: записи внутри `f` happens-before возврат любого `Do` → все горутины видят полностью проинициализированное состояние.
- Если `f` паникует, она считается «выполненной» — повторные `Do` её не запустят.

### Устройство под капотом
```go
type Once struct {
    done atomic.Uint32 // 0 = не выполнено, 1 = выполнено
    m    Mutex
}

func (o *Once) Do(f func()) {
    if o.done.Load() == 0 { // быстрый путь: атомарное чтение
        o.doSlow(f)
    }
}

func (o *Once) doSlow(f func()) {
    o.m.Lock()
    defer o.m.Unlock()
    if o.done.Load() == 0 {     // двойная проверка под мьютексом
        defer o.done.Store(1)   // ставим флаг ПОСЛЕ f (через defer)
        f()
    }
}
```

Ключевые детали:
- **Double-checked locking**, корректный благодаря memory model Go. Быстрый путь — атомарный `Load` без захвата мьютекса (дёшево после инициализации).
- `done.Store(1)` стоит в `defer` **после** `f()` — поэтому конкурентные вызовы, ждущие на мьютексе, увидят `done==1` только когда `f` реально завершилась. Это и даёт happens-before.
- Почему именно атомик, а не просто `if o.done == 1`? Без атомарного `Store/Load` другая горутина могла бы увидеть `done==1`, но не увидеть записи `f` из-за переупорядочивания/кэшей — гонка данных. Атомик с release-семантикой при Store и acquire при Load это исключает.

### Go 1.21: OnceFunc / OnceValue / OnceValues
Удобные обёртки, скрывающие переменную Once:

```go
// OnceFunc: f выполнится один раз; возвращает функцию-обёртку
init := sync.OnceFunc(func() { expensiveSetup() })
init(); init() // setup один раз

// OnceValue: ленивое вычисление значения с кэшированием
getConfig := sync.OnceValue(func() Config { return loadConfig() })
c := getConfig() // loadConfig один раз, дальше кэш

// OnceValues: два возвращаемых значения (часто value+error)
getDB := sync.OnceValues(func() (*DB, error) { return connect() })
db, err := getDB()
```

Семантика паники: если функция в `OnceFunc`/`OnceValue` паникует, обёртка **запоминает панику** и при каждом последующем вызове **перевыбрасывает её же** (re-panic), а не запускает функцию заново и не возвращает «пустое» значение. Это важное отличие — детерминированное поведение при сбое инициализации.

## Подводные камни / gotchas
- **Once не сбрасывается.** Нет `Reset`. Нужна повторная инициализация (например, переподключение) — это не задача Once; используйте отдельную структуру с мьютексом или новый экземпляр Once.
- **Паника = «выполнено».** Если `f` упала, `done` всё равно станет 1 (через defer), и повтор не запустит её. Состояние останется неинициализированным, а ошибки вы не увидите. Для инициализации, которая может сбоить, используйте `OnceValues` (вернёт error) или собственную логику с проверкой и возможностью повтора.
- **Дедлок: вложенный `Do` того же Once.** Вызов `once.Do` изнутри его же `f` → попытка повторного захвата `o.m` той же горутиной → самодедлок (мьютекс не reentrant).
- **Копирование Once** после использования запрещено (`copylocks`). Передавайте по указателю; обычно Once — поле структуры или package-level переменная.
- **Захват результата.** Сам `Do` ничего не возвращает; значение нужно писать в внешнюю переменную (видимость гарантирована happens-before). `OnceValue` решает это эргономичнее.
- **Не для «один раз на запрос».** Once — на всё время жизни процесса/экземпляра. Для «один раз на единицу работы» нужен другой механизм.

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

**В:** Как работает быстрый путь `Do`?
**О:** Атомарное чтение `done`. Если уже 1 — мгновенный возврат без захвата мьютекса. Это делает повторные вызовы почти бесплатными после инициализации.

**В:** Почему нельзя обойтись простым булевым флагом без atomic?
**О:** Без атомарных операций возможна гонка данных: одна горутина видит `done==1`, но из-за отсутствия acquire/release-барьеров может не увидеть записи, сделанные в `f`. Атомарный Store (release) после `f` и Load (acquire) гарантируют видимость и happens-before.

**В:** Почему `done` ставится в defer после f, а не до?
**О:** Чтобы конкурентные вызовы, заблокированные на мьютексе, увидели `done==1` только после реального завершения `f`. Если бы флаг ставился до вызова, другая горутина могла бы выйти из Do, считая инициализацию готовой, пока `f` ещё работает.

**В:** Что будет, если `f` паникует?
**О:** В классическом `Once.Do` флаг всё равно установится (defer), и `f` больше не запустится — состояние останется неинициализированным. В `OnceFunc`/`OnceValue` (1.21) паника кэшируется и перевыбрасывается при каждом следующем вызове.

**В:** Можно ли вызвать `once.Do` внутри переданной функции?
**О:** Нет, это самодедлок: `f` выполняется под захваченным `o.m`, повторный `Do` попытается захватить его снова, мьютекс не реентрантный.

**В:** В чём разница OnceFunc, OnceValue, OnceValues?
**О:** `OnceFunc` оборачивает функцию без возврата. `OnceValue[T]` кэширует одно значение. `OnceValues[T1,T2]` — два (обычно value+error). Все скрывают переменную Once и единообразно обрабатывают панику.

**В:** Как сделать инициализацию, которая может повторяться при ошибке?
**О:** Once не подходит (он «выполнено» даже при ошибке). Нужна структура с мьютексом и явным флагом успеха, проверяющая ошибку и допускающая повтор, либо `OnceValues` если повтор не нужен и достаточно вернуть сохранённую ошибку.

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

## На что копают на senior+
- Double-checked locking и почему он корректен в Go (в отличие от старой Java без volatile) — release/acquire семантика atomic.
- Точное место установки `done` (defer после f) и его связь с happens-before гарантией для ждущих на мьютексе.
- Кэширование паники в `OnceFunc`/`OnceValue`: как реализовано через сохранение recover-значения и re-panic.
- Почему в Go нет `Once.Reset` и какие паттерны заменяют «переинициализацию» (atomic.Pointer swap, новый экземпляр).
- Сравнение с package-level `init()` (всегда выполняется, не ленивый) и с `var x = compute()` (тоже при инициализации пакета, не лениво).