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
`sync/atomic` даёт атомарные операции над одиночными словами (load/store/add/swap/CAS), реализованные аппаратными инструкциями (LOCK-префикс на x86, LL/SC или CASAL на ARM) без блокировок и парковки горутин. Go 1.19 ввёл типобезопасные обёртки `atomic.Int64`, `atomic.Pointer[T]`, `atomic.Bool` и др., которые нельзя случайно скопировать и которые гарантируют выравнивание. Atomic — для простых счётчиков/флагов/указателей и lock-free структур; для составных инвариантов (несколько связанных полей) нужен мьютекс.

## Теория

### Операции
- **Load / Store** — атомарное чтение/запись слова целиком (без «разорванной» записи).
- **Add** — атомарный инкремент/декремент, возвращает новое значение.
- **Swap** — атомарно записать новое и вернуть старое.
- **CompareAndSwap (CAS)** — если текущее значение == old, записать new, вернуть успех. Фундамент lock-free алгоритмов.

```go
var n atomic.Int64
n.Add(1)
v := n.Load()

// CAS-цикл (классический lock-free паттерн)
for {
    old := n.Load()
    next := compute(old)
    if n.CompareAndSwap(old, next) {
        break // успех: никто не вмешался между Load и CAS
    }
    // кто-то изменил n — повторяем
}
```

### Типобезопасные обёртки (Go 1.19+)
```go
var (
    flag atomic.Bool
    cnt  atomic.Uint64
    cfg  atomic.Pointer[Config]
    val  atomic.Value // для произвольного типа, тип фиксируется первым Store
)
```
Преимущества над старыми функциями `atomic.AddInt64(&x, 1)`:
- **Нельзя случайно сделать неатомарный доступ** (`x++` мимо atomic) — поле приватное.
- **`noCopy`** — go vet ловит копирование.
- **Гарантия выравнивания**: на 32-битных платформах старый `int64` требовал ручного 8-байтного выравнивания (первое поле структуры), иначе паника в рантайме. Обёртки решают это сами.
- `atomic.Pointer[T]` — типизированный, без `unsafe.Pointer` в пользовательском коде.

### atomic.Value и atomic.Pointer для copy-on-write
Read-heavy конфиг без блокировок у читателей:
```go
var cfg atomic.Pointer[Config]

func Get() *Config { return cfg.Load() }      // читатели — без блокировки
func Update(c *Config) { cfg.Store(c) }        // писатель публикует новый снапшот
```
Читатели берут неизменяемый снапшот; писатель строит новую структуру и атомарно подменяет указатель. Старые читатели продолжают видеть прежний снапшот (он жив, пока на него есть ссылки — GC соберёт позже).

### Memory ordering в Go
Go **не даёт** программисту выбора порядка (нет `relaxed`/`acquire`/`release` как в C++). Модель проще:
- Все atomic-операции в Go — **sequentially consistent** (с Go 1.19 это явно зафиксировано в memory model).
- Атомарная запись, наблюдаемая атомарным чтением, устанавливает **happens-before** между ними: всё, что записано до atomic Store, видно после atomic Load этого значения.
- Это значит: atomic-флаг можно использовать как барьер публикации данных (как `done` в `sync.Once`).

Под капотом компилятор вставляет нужные барьеры/инструкции: на x86 (сильная модель) обычные load/store почти бесплатны, нужен барьер в основном для CAS/Add (LOCK); на ARM/ARM64 (слабая модель) вставляются `dmb`/используются acquire-release инструкции (LDAR/STLR, CASAL).

### Когда atomic вместо mutex
| Сценарий | atomic | mutex |
|---|---|---|
| Счётчик, флаг, один указатель | да | избыточно |
| Несколько связанных полей (инвариант) | нет (нельзя обновить атомарно) | да |
| Длинная критическая секция, I/O | нет | да |
| Copy-on-write снапшот | atomic.Pointer | можно, но дороже читателям |
| Высокая частота, простая операция | да (без парковки) | возможен contention |

Atomic выигрывает на простых операциях: нет захвата мьютекса, нет парковки/побудки горутин, нет переключения контекста. Но при высокой конкуренции CAS-цикл может крутиться (много retry) и тоже грузить шину когерентности — не всегда быстрее мьютекса.

## Подводные камни / gotchas
- **Atomic защищает только одну переменную.** Два связанных atomic-поля нельзя обновить атомарно вместе — между обновлениями возможна гонка логики. Для инварианта над несколькими полями — мьютекс или один atomic.Pointer на всю структуру (COW).
- **Смешивание atomic и обычного доступа** к той же переменной — гонка данных (`-race` ловит). Если переменная atomic, **все** обращения к ней должны быть atomic.
- **Старый API на 32-битах:** `atomic.AddInt64(&x, ...)` требует 8-байтного выравнивания `x`; невыровненный → паника. Типизированные обёртки (1.19) снимают эту боль — предпочитайте их.
- **ABA-проблема в CAS.** Значение могло смениться A→B→A; CAS пройдёт, хотя «что-то происходило». Для lock-free структур (стеки, очереди) это реальный риск; решают версионными счётчиками/тегами или иными приёмами.
- **Busy CAS-цикл под высокой конкуренцией** жжёт CPU и может голодать. Иногда мьютекс (с парковкой) эффективнее.
- **Копирование структуры с atomic-полем** ломает атомарность; go vet (через noCopy) предупреждает.
- **`atomic.Value`:** все Store должны быть **одного конкретного типа**, иначе паника. Нельзя Store(nil) первым.

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

**В:** Что такое CAS и зачем нужен?
**О:** Compare-And-Swap: атомарно проверяет, что значение равно ожидаемому old, и только тогда записывает new. Возвращает успех/неудачу. Это основа lock-free алгоритмов: в цикле читаем состояние, вычисляем новое, пытаемся CAS; при неудаче (кто-то вмешался) повторяем.

**В:** Какую модель памяти даёт atomic в Go?
**О:** Sequentially consistent (явно с Go 1.19). Дополнительно атомарная запись, прочитанная атомарным чтением, создаёт happens-before — записи до Store видны после соответствующего Load. В Go нет relaxed/acquire/release на выбор, как в C++.

**В:** Когда брать atomic, а когда mutex?
**О:** Atomic — для одиночной переменной: счётчик, флаг, указатель, lock-free снапшот. Mutex — когда нужно атомарно обновить несколько связанных полей (инвариант), длинная критическая секция или сложная логика. Atomic не умеет согласованно менять две переменные сразу.

**В:** Зачем нужны типизированные обёртки 1.19, если есть atomic.AddInt64?
**О:** Они предотвращают случайный неатомарный доступ (поле приватно), запрещают копирование (noCopy/go vet), гарантируют выравнивание на 32-бит платформах и дают типобезопасный `Pointer[T]` без unsafe. Старый API легко использовать неправильно.

**В:** Что такое ABA-проблема?
**О:** Значение меняется A→B→A, и CAS на A проходит, хотя между чтением и CAS состояние менялось. Для lock-free структур это может привести к некорректности (например, переиспользованный узел). Решают версионными тегами/счётчиками поколений.

**В:** Можно ли читать atomic-переменную обычным чтением?
**О:** Нет, это гонка данных. Если переменная атомарная, все доступы (и чтение, и запись) должны идти через atomic-операции. Смешивание ловит race detector.

**В:** Как сделать lock-free read-heavy конфиг?
**О:** `atomic.Pointer[Config]`: читатели делают `Load()` (без блокировки), писатель строит новый неизменяемый Config и `Store()` подменяет указатель (copy-on-write). Старые снапшоты живут, пока есть ссылки, потом собираются GC.

**В:** Всегда ли atomic быстрее мьютекса?
**О:** Нет. На простых неконкурентных операциях — да (нет парковки/контекст-свитча). Но под высокой конкуренцией CAS-цикл может много раз ретраить и грузить когерентность кэшей; иногда мьютекс с парковкой эффективнее. Нужно мерить.

**В:** Что особенного в atomic на 32-битных платформах?
**О:** 64-битные атомарные операции требуют 8-байтного выравнивания; невыровненный адрес → паника. Раньше приходилось ставить int64 первым полем структуры. Типизированные обёртки (1.19) обеспечивают выравнивание автоматически.

## На что копают на senior+
- Аппаратная реализация: LOCK-префикс x86 vs LL/SC и CASAL/LDAR/STLR на ARM64; стоимость барьеров на сильной vs слабой модели памяти.
- Go memory model и формулировка happens-before для atomic (изменения в 1.19, согласование с C/C++11 SC).
- Lock-free дизайн: CAS-циклы, ABA, hazard pointers/эпохи, почему GC в Go упрощает reclamation памяти по сравнению с C++.
- Copy-on-write на atomic.Pointer: жизненный цикл снапшотов, взаимодействие с GC, отсутствие блокировки у читателей.
- False sharing атомарных счётчиков и padding до cache line; почему «горячий» atomic.Int64 в структуре бьёт по соседним полям.
- Когда CAS-loop проигрывает мьютексу под contention и как это профилировать.