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
Базовый словарь конкурентного Go: pipeline (этапы через каналы), fan-out/fan-in (распараллелить этап и собрать), worker pool (фиксированный пул на канале задач), семафор (ограничение конкуренции буферизованным каналом), `errgroup` (группа горутин с отменой и первой ошибкой), graceful shutdown (через context + WaitGroup), or-done (обёртка для отмены). Общий принцип всех паттернов: **у каждой горутины есть явный путь завершения** (закрытие входа или `ctx.Done()`), иначе — утечка.

## Теория

### Pipeline
Этапы, соединённые каналами; каждый этап читает вход, пишет выход, **закрывает свой выход** при завершении.
```go
func gen(ctx context.Context, nums ...int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for _, n := range nums {
            select {
            case out <- n:
            case <-ctx.Done():
                return
            }
        }
    }()
    return out
}

func sq(ctx context.Context, in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for n := range in {
            select {
            case out <- n * n:
            case <-ctx.Done():
                return
            }
        }
    }()
    return out
}
```
Правило: **закрывает канал тот, кто в него пишет** (producer), и только он. Закрытие распространяется по цепочке через `range`.

### Fan-out / Fan-in
**Fan-out** — несколько горутин читают из одного канала (распараллелили этап). **Fan-in** — слить несколько каналов в один.
```go
func fanIn(ctx context.Context, chans ...<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup
    for _, c := range chans {
        wg.Add(1)
        go func(c <-chan int) {
            defer wg.Done()
            for v := range c {
                select {
                case out <- v:
                case <-ctx.Done():
                    return
                }
            }
        }(c)
    }
    go func() { wg.Wait(); close(out) }() // закрыть out, когда все источники иссякли
    return out
}
```

### Worker pool
Фиксированное число воркеров на общем канале задач — ограничивает параллелизм и переиспользует горутины.
```go
func pool(ctx context.Context, jobs <-chan Job, n int) <-chan Result {
    results := make(chan Result)
    var wg sync.WaitGroup
    for i := 0; i < n; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for j := range jobs {
                select {
                case results <- process(j):
                case <-ctx.Done():
                    return
                }
            }
        }()
    }
    go func() { wg.Wait(); close(results) }()
    return results
}
```
Размер пула: для CPU-bound ≈ `GOMAXPROCS`; для I/O-bound — больше (зависит от внешних лимитов).

### Semaphore (ограничение конкуренции)
Буферизованный канал ёмкости N как счётный семафор:
```go
sem := make(chan struct{}, maxConcurrent)
for _, task := range tasks {
    sem <- struct{}{}           // занять слот (блокирует при N занятых)
    go func(t Task) {
        defer func() { <-sem }() // освободить
        handle(t)
    }(task)
}
```
Альтернатива с весами и context-отменой — `golang.org/x/sync/semaphore` (`Acquire(ctx, n)`).

### errgroup
`golang.org/x/sync/errgroup` — WaitGroup + первая ошибка + отмена контекста.
```go
g, ctx := errgroup.WithContext(ctx)
g.SetLimit(8) // ограничение параллелизма (опционально)
for _, url := range urls {
    url := url
    g.Go(func() error {
        return fetch(ctx, url) // вернёт ошибку → ctx отменится для остальных
    })
}
if err := g.Wait(); err != nil { // первая ненулевая ошибка
    return err
}
```
`WithContext` отменяет `ctx`, как только любая горутина вернула ошибку → остальные, проверяющие `ctx.Done()`, быстро завершаются. `Wait` возвращает первую ошибку. `SetLimit` встроенно ограничивает конкуренцию.

### Graceful shutdown горутин
Контекст для отмены + WaitGroup для ожидания завершения:
```go
func run(ctx context.Context) error {
    ctx, stop := signal.NotifyContext(ctx, os.Interrupt, syscall.SIGTERM)
    defer stop()

    var wg sync.WaitGroup
    wg.Add(1)
    go worker(ctx, &wg)

    <-ctx.Done()        // дождались сигнала/отмены
    // здесь можно дать дедлайн на graceful: shutdownCtx с таймаутом
    wg.Wait()           // дождались, что воркеры дочистили
    return nil
}
```
Паттерн: сигнал → отмена ctx → воркеры видят `ctx.Done()` и завершаются → `wg.Wait()` гарантирует, что они дочистили ресурсы → при необходимости таймаут на shutdown, чтобы не висеть вечно.

### Or-done channel
Обёртка, которая прекращает чтение из канала при отмене — убирает дублирование select в каждом потребителе.
```go
func orDone[T any](ctx context.Context, in <-chan T) <-chan T {
    out := make(chan T)
    go func() {
        defer close(out)
        for {
            select {
            case v, ok := <-in:
                if !ok { return }
                select {
                case out <- v:
                case <-ctx.Done():
                    return
                }
            case <-ctx.Done():
                return
            }
        }
    }()
    return out
}

// потребитель чистый:
for v := range orDone(ctx, source) { use(v) }
```

### tee, bridge
- **tee** — раздваивает один канал на два (каждое значение уходит в оба).
- **bridge** — «склеивает» канал каналов (`<-chan <-chan T`) в один поток.

## Подводные камни / gotchas
- **Закрытие канала не тем, кто пишет.** Закрывать должен единственный producer. Закрытие из получателя или из нескольких писателей → паника «send on closed channel»/«close of closed channel».
- **Нет ветки отмены** в долгоживущей горутине → утечка при раннем выходе потребителя. Каждая блокирующая операция в фоне должна иметь `ctx.Done()`.
- **`wg.Wait(); close(out)` пропущен** в fan-in → out никогда не закроется, `range` зависнет.
- **Неограниченный fan-out** (`go` на каждый элемент без семафора/пула) → взрыв числа горутин, OOM, перегрузка downstream. Ограничивайте пулом/семафором/`SetLimit`.
- **errgroup без проверки ctx внутри функций** — отмена не сработает: горутины должны сами реагировать на `ctx.Done()`. errgroup лишь отменяет контекст.
- **Buffered-канал не «починит» отсутствие потребителя** — он лишь отсрочит блокировку/утечку.
- **Graceful без таймаута** — если воркер завис, `wg.Wait()` будет ждать вечно. Дайте дедлайн на shutdown.
- **Захват переменной цикла** до Go 1.22 требовал копии (`url := url`); в 1.22+ loopvar per-iteration, но в `errgroup.Go`/горутинах всё равно держите это в голове на старых версиях.

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

**В:** Кто должен закрывать канал и почему?
**О:** Только отправитель (producer), и только один. Получатель закрывать не должен — это приведёт к панике при следующей отправке. При нескольких писателях используют отдельную координацию (WaitGroup + закрытие после Wait единственной горутиной).

**В:** Чем fan-out отличается от worker pool?
**О:** Fan-out — общая идея «много горутин читают один канал». Worker pool — конкретная реализация с **фиксированным** числом переиспользуемых воркеров, что ограничивает параллелизм и не плодит горутины на каждый элемент.

**В:** Как ограничить число одновременных операций?
**О:** Буферизованный канал-семафор ёмкости N (занять перед, освободить после), worker pool из N воркеров, `errgroup.SetLimit(N)` или `x/sync/semaphore` с весами и context-отменой.

**В:** Что даёт errgroup поверх WaitGroup?
**О:** Сбор первой ошибки, отмену общего контекста при первой ошибке (`WithContext`), опциональный лимит параллелизма (`SetLimit`) и удобный `Go(func() error)`. WaitGroup только считает завершения.

**В:** Как реализовать graceful shutdown горутин?
**О:** Передать всем `context`, по сигналу (signal.NotifyContext) отменить его; горутины реагируют на `ctx.Done()` и завершаются, освобождая ресурсы; `wg.Wait()` дожидается завершения. Обязательно с таймаутом на shutdown, иначе зависшая горутина повесит процесс.

**В:** Зачем нужен or-done паттерн?
**О:** Чтобы не дублировать `select { case v := <-in: ...; case <-ctx.Done(): }` в каждом потребителе. or-done оборачивает входной канал и сам прекращает поток при отмене, давая потребителю чистый `for range`.

**В:** Как правильно закрыть выходной канал fan-in?
**О:** Каждая копирующая горутина в WaitGroup; отдельная горутина делает `wg.Wait(); close(out)`. Так out закроется ровно когда все источники иссякли, и `range out` корректно завершится.

**В:** Какой размер пула выбрать?
**О:** Для CPU-bound ≈ `runtime.GOMAXPROCS` (число логических ядер). Для I/O-bound — больше, ограничено внешними лимитами (пул соединений БД, rate limit API). Замеряйте: слишком много воркеров создаёт contention и перегружает downstream.

**В:** Почему неограниченный `go` на каждый элемент опасен?
**О:** Число горутин неконтролируемо растёт при большом/бесконечном вводе → память, давление на планировщик, перегрузка downstream-сервисов. Нужен пул/семафор/лимит.

## На что копают на senior+
- Дисциплина владения каналами: единственный writer закрывает; распространение close по pipeline; почему close — это broadcast.
- Корректная отмена сквозь все этапы pipeline (ctx в каждом select) и доказательство отсутствия утечек.
- errgroup внутри: как `WithContext` отменяет, как `SetLimit` реализован (семафор), порядок возврата ошибки.
- Backpressure в pipeline: небуферизованные каналы как естественный контроль потока vs буферизация.
- Graceful shutdown с дедлайном, дренаж очередей, идемпотентность, порядок остановки этапов.
- Generic-обёртки (orDone/tee/bridge на дженериках 1.18+) и их влияние на читаемость/производительность.