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/


> Модуль: Распределённые системы · Уровень: Senior+

## TL;DR
- Ретрай — это попытка повторить запрос после сбоя. Наивный «повторить сразу N раз» в распределённой системе создаёт **retry storm** и усиливает деградацию.
- Базовая формула паузы: **exponential backoff** (`base * 2^attempt`) с **cap** (потолком) и **jitter** (рандомизацией), чтобы избежать синхронизации клиентов (thundering herd).
- Лучший дефолт — **decorrelated jitter** или **full jitter** (по статье AWS «Exponential Backoff And Jitter»).
- Ретраить можно **только идемпотентные операции** (или операции, защищённые idempotency key). Иначе риск двойного списания/дублей.
- **Retry budget** ограничивает долю ретраев от общего трафика (например, не более 10–20%), предотвращая каскадное усиление нагрузки.
- **Deadline propagation** через `context.Context`: общий дедлайн всего вызова пробрасывается вниз, и каждая попытка (включая backoff) обязана в него укладываться.
- Ретраить осмысленно: transient-ошибки (5xx, timeout, connection reset), а не 4xx (кроме 429/503 с Retry-After).

## Теория

### Зачем вообще ретраи
В распределённой системе сбои — норма, а не исключение: сетевые таймауты, кратковременная недоступность пода во время rolling update, GC-пауза на сервере, потеря пакета. Многие из них **transient** — повторная попытка через короткое время с высокой вероятностью пройдёт. Ретрай повышает наблюдаемую надёжность (availability) без изменения самого сервиса.

Опасность: ретрай — это **усилитель нагрузки**. Если downstream уже перегружен и отвечает ошибками, наивные ретраи добавляют ещё больше запросов ровно в тот момент, когда сервису плохо. Это превращает локальную деградацию в **cascading failure**.

### Exponential backoff
Идея: каждая следующая попытка ждёт экспоненциально дольше, давая downstream время восстановиться.

```
sleep = min(cap, base * 2^attempt)
```

- `base` — стартовая задержка (например, 100 ms).
- `attempt` — номер попытки (0, 1, 2, ...).
- `cap` — потолок, чтобы паузы не росли до минут (например, 10 s).

Пример без jitter (base=100ms, cap=10s):

| attempt | задержка |
|---------|----------|
| 0 | 100 ms |
| 1 | 200 ms |
| 2 | 400 ms |
| 3 | 800 ms |
| 4 | 1600 ms |
| 7 | 10 s (cap) |

Проблема чистого экспоненциального backoff: если 1000 клиентов получили ошибку **одновременно** (например, сервис мигнул на 1 секунду), они все будут ждать ровно 100 ms, потом ровно 200 ms — и **синхронно бомбардировать** downstream волнами. Это **thundering herd / retry synchronization**.

### Jitter — рандомизация для рассинхронизации
Jitter добавляет случайность в задержку, размазывая волну ретраев во времени. Три классических варианта (терминология из AWS Architecture Blog):

**1. Full jitter** — равномерно случайно от 0 до экспоненциального значения:
```
sleep = random(0, min(cap, base * 2^attempt))
```
Максимально размазывает нагрузку. Минус: иногда даёт очень маленькие паузы (близко к 0), то есть слабее «отдыхает».

**2. Equal jitter** — половина фиксирована, половина случайна:
```
temp  = min(cap, base * 2^attempt)
sleep = temp/2 + random(0, temp/2)
```
Компромисс: гарантирует минимальную паузу и при этом рассинхронизирует. На практике по бенчмаркам AWS почти всегда уступает full/decorrelated.

**3. Decorrelated jitter** — задержка зависит от предыдущей задержки, а не от номера попытки:
```
sleep = min(cap, random(base, prev_sleep * 3))
```
Где `prev_sleep` стартует с `base`. Даёт хорошее покрытие диапазона и быстрое восстановление при минимуме лишних запросов. По исследованию AWS — лучший общий выбор по соотношению «число вызовов / время завершения».

> Вывод из статьи AWS: **любой jitter драматически снижает число лишних вызовов** по сравнению с backoff без jitter. Full jitter и decorrelated jitter — практически равны и оба хороши. Equal jitter — слабее.

ASCII-иллюстрация thundering herd:

```
Без jitter (все ждут одинаково):        С full jitter (размазано):
t=100ms  ████████████ (1000 req)        t=20ms   ██
t=200ms  ████████████ (1000 req)        t=50ms   ███
t=400ms  ████████████ (1000 req)        t=90ms   ████
         волны добивают downstream      t=130ms  ███  ... равномерно
```

### Retry budgets (бюджеты ретраев)
Ограничение количества ретраев «N попыток на запрос» не контролирует **системную** нагрузку: при массовом сбое каждый из миллионов запросов делает свои 3 ретрая → 3x трафика по всему флоту.

**Retry budget** ограничивает ретраи как **долю от общего числа запросов** за окно времени. Например, политика «ретраи не должны превышать 20% от основного трафика». Когда бюджет исчерпан — ретраи временно отключаются, запрос падает сразу.

Так делают gRPC (`retryThrottling` с `maxTokens`/`tokenRatio`), Envoy, Finagle, Linkerd. Token-bucket подход:
- Каждый исходный запрос добавляет токены.
- Каждый ретрай тратит токены.
- Нет токенов → ретраи запрещены.

Это превращает «жёсткий лимит на запрос» в «адаптивный лимит на сервис», который автоматически глушит ретраи при широком сбое и не мешает им при единичных ошибках.

### Что можно ретраить: идемпотентность как предусловие
Ретрай безопасен, только если повторное выполнение операции не вызывает побочного эффекта дважды. Это **идемпотентность**.

- **Идемпотентны по природе:** `GET`, `PUT` (полная замена), `DELETE`, чтение.
- **НЕ идемпотентны:** `POST /payments`, «списать деньги», «отправить email», «инкремент счётчика».

Особо коварен случай: запрос **дошёл и выполнился**, но ответ потерялся (таймаут на ответе). Клиент думает «не получилось» и ретраит → двойное списание.

Решение для неидемпотентных операций — **idempotency key**: клиент генерирует уникальный ключ на логическую операцию и шлёт его при каждой попытке. Сервер дедуплицирует по ключу (сохраняет результат первого выполнения и возвращает его на повторах). Тогда операция становится идемпотентной на уровне протокола, и ретрай снова безопасен.

> Правило: **ретраи и идемпотентность — неразделимы**. Прежде чем включать ретраи на write-эндпоинте, ответь: что произойдёт, если запрос выполнится дважды?

### Timeout и deadline propagation
Ретраи бессмысленны без таймаутов: попытка должна иметь верхнюю границу, иначе зависший вызов блокирует всю цепочку.

Два уровня:
- **Per-attempt timeout** — таймаут на одну попытку.
- **Overall deadline** — общий дедлайн на весь вызов (включая все ретраи и паузы backoff).

Критично пробрасывать дедлайн вниз по цепочке через `context.Context`. Если у клиента осталось 200 ms, бессмысленно начинать попытку с таймаутом 1 s или ждать backoff 500 ms. **Deadline propagation** означает, что каждый downstream-вызов знает оставшийся бюджет времени и не делает работу, которую заведомо не успеет отдать (защита от «зомби»-работы).

```
Запрос A (deadline=1s)
  └─> вызов B (передаём оставшийся deadline)
        └─> вызов C (передаём оставшийся deadline)
```
Если у A истёк дедлайн, отмена через context каскадно прерывает B и C.

### Retry storms / cascading failures
Сценарий каскада:
1. Сервис D начинает медленно отвечать (перегрузка / GC).
2. Вызовы в D таймаутятся, клиенты ретраят.
3. Нагрузка на D растёт в 2–3 раза от ретраев → D совсем ложится.
4. Сервис C, зависящий от D, копит зависшие горутины/коннекты, тоже деградирует и тоже начинает ретраить.
5. Деградация поднимается вверх по графу зависимостей — **cascading failure**.

Защитный набор (defense in depth):
- backoff + jitter (рассинхронизация),
- retry budget (ограничение доли ретраев),
- **circuit breaker** (fail fast при устойчивых ошибках — см. соседний материал),
- дедлайны и их проброс,
- **не ретраить на нескольких уровнях стека одновременно** (если ретраит и клиент, и сервис-посредник, и SDK — эффект множится: 3 уровня по 3 попытки = до 27 запросов).

### Пример на Go: backoff + jitter + deadline + ретрай только transient
```go
package retry

import (
	"context"
	"errors"
	"math"
	"math/rand"
	"time"
)

type Policy struct {
	MaxAttempts int           // верхняя граница попыток
	Base        time.Duration // стартовая задержка
	Cap         time.Duration // потолок задержки
}

// retryable решает, имеет ли смысл повторять. Только transient-ошибки.
type retryable interface{ Retryable() bool }

func isRetryable(err error) bool {
	var r retryable
	if errors.As(err, &r) {
		return r.Retryable()
	}
	// по умолчанию — таймауты/отмену контекста не считаем "сетевым transient",
	// они означают, что бюджет времени исчерпан.
	return false
}

// fullJitter: random(0, min(cap, base*2^attempt))
func fullJitter(p Policy, attempt int) time.Duration {
	backoff := float64(p.Base) * math.Pow(2, float64(attempt))
	backoff = math.Min(backoff, float64(p.Cap))
	return time.Duration(rand.Int63n(int64(backoff) + 1))
}

// Do выполняет op с ретраями. Уважает общий дедлайн из ctx.
func Do(ctx context.Context, p Policy, op func(ctx context.Context) error) error {
	var lastErr error
	for attempt := 0; attempt < p.MaxAttempts; attempt++ {
		// per-attempt контекст наследует общий дедлайн -> deadline propagation
		err := op(ctx)
		if err == nil {
			return nil
		}
		lastErr = err
		if !isRetryable(err) {
			return err // неретраиваемая ошибка — выходим сразу
		}
		if attempt == p.MaxAttempts-1 {
			break
		}

		delay := fullJitter(p, attempt)

		// если backoff не укладывается в оставшийся дедлайн — нет смысла ждать
		if dl, ok := ctx.Deadline(); ok && time.Now().Add(delay).After(dl) {
			return lastErr
		}

		select {
		case <-ctx.Done():
			return ctx.Err() // дедлайн/отмена пробрасываются вверх
		case <-time.After(delay):
		}
	}
	return lastErr
}
```

Использование с общим дедлайном:
```go
ctx, cancel := context.WithTimeout(parent, 2*time.Second) // overall deadline
defer cancel()

p := retry.Policy{MaxAttempts: 4, Base: 50 * time.Millisecond, Cap: 1 * time.Second}

err := retry.Do(ctx, p, func(ctx context.Context) error {
	// per-attempt таймаут, но не больше оставшегося бюджета ctx
	attemptCtx, c := context.WithTimeout(ctx, 500*time.Millisecond)
	defer c()
	return callDownstream(attemptCtx) // должен вернуть ошибку с Retryable()
})
```

Для production предпочтительнее проверенные библиотеки: `cenkalti/backoff/v4`, `avast/retry-go`, gRPC service config retry policy, либо встроенные retry-механизмы service mesh (Envoy/Istio/Linkerd), где budget и backoff конфигурируются декларативно.

## Подводные камни / gotchas
- **Ретрай неидемпотентной операции без idempotency key** — классика двойного списания. Особенно при потере ответа после успешного выполнения.
- **Ретраи на каждом уровне стека** (клиент + прокси + SDK) перемножаются. Решение: ретраить на одном уровне, остальные — passthrough.
- **Backoff без cap** — задержки уходят в минуты, попытки висят дольше, чем имеет смысл.
- **Backoff без jitter** — thundering herd, синхронные волны добивают downstream.
- **Игнор дедлайна при backoff** — ждём 1s паузу, когда у запроса осталось 200ms.
- **Ретрай 4xx-ошибок** — `400/401/403/404` детерминированно повторятся с тем же результатом, это бесполезная нагрузка. Исключения: `429 Too Many Requests` и `503` с заголовком `Retry-After`.
- **Ретрай по `context.DeadlineExceeded`** — обычно бессмысленно: дедлайн уже истёк, новая попытка не успеет.
- **`math/rand` без правильного использования** — глобальный источник под мьютексом может стать точкой контеншена при высоком RPS; в Go 1.20+ глобальный источник авто-сидируется, но для горячего пути используйте `rand.New(rand.NewSource(...))` на горутину или `math/rand/v2`.
- **Нет retry budget** — единичная политика «3 попытки» при массовом сбое = 3x нагрузка на весь флот.
- **Ретрай не-thread-safe тела op** — если op мутирует общее состояние/переиспользует body запроса (`io.Reader` уже вычитан), повтор сломается. HTTP-тело нужно уметь пересоздать (`GetBody`).

## Вопросы на собеседовании
**В:** Зачем нужен jitter, если уже есть exponential backoff?
**О:** Backoff разносит попытки одного клиента во времени, но не рассинхронизирует **разных** клиентов: если все получили ошибку одновременно, они ждут одинаковые интервалы и бьют downstream синхронными волнами (thundering herd). Jitter добавляет случайность, размазывая ретраи во времени и снижая пиковую нагрузку. По данным AWS, jitter резко уменьшает число лишних вызовов.

**В:** В чём разница между full, equal и decorrelated jitter?
**О:** Full jitter — `random(0, exp)`, максимально размазывает, но иногда даёт почти нулевые паузы. Equal jitter — `exp/2 + random(0, exp/2)`, гарантирует минимальную паузу. Decorrelated jitter — `random(base, prev*3)`, зависит от предыдущей паузы, а не от номера попытки, даёт хорошее покрытие диапазона. На практике full и decorrelated близки и лучшие; equal слабее.

**В:** Какие операции можно ретраить?
**О:** Только идемпотентные — те, где повторное выполнение не даёт дополнительного побочного эффекта (GET, PUT, DELETE). Неидемпотентные (POST-платёж, отправка письма) нельзя ретраить вслепую; их делают безопасными через idempotency key и серверную дедупликацию.

**В:** Запрос на списание денег ушёл, сервер списал, но ответ потерялся по таймауту. Клиент ретраит. Что произойдёт и как защититься?
**О:** Без защиты — двойное списание, потому что клиент не знает, что первая попытка реально выполнилась. Защита: idempotency key, генерируемый клиентом один раз на логическую операцию; сервер сохраняет результат по ключу и на повторе возвращает тот же результат вместо повторного списания.

**В:** Что такое retry budget и чем он лучше «N попыток на запрос»?
**О:** «N попыток» — локальный лимит, не контролирующий системную нагрузку: при широком сбое каждый запрос множит трафик в N раз по всему флоту. Retry budget ограничивает ретраи как долю от общего трафика (token bucket): при массовом сбое бюджет исчерпывается и ретраи глушатся, а единичные ошибки ретраятся свободно. Так делают gRPC retryThrottling, Envoy, Linkerd.

**В:** Что такое cascading failure и как ретраи его провоцируют?
**О:** Каскадный отказ — деградация одного сервиса распространяется вверх по графу зависимостей. Ретраи усиливают нагрузку на уже перегруженный downstream в 2–3 раза, добивая его, после чего деградируют зависящие сервисы. Защита: backoff+jitter, retry budget, circuit breaker (fail fast), дедлайны, отказ от многоуровневых ретраев.

**В:** Как ретраи связаны с context и дедлайнами?
**О:** Общий дедлайн вызова хранится в context и пробрасывается вниз (deadline propagation). Каждая попытка плюс пауза backoff должны укладываться в оставшийся бюджет; если backoff не влезает — лучше упасть сразу. Отмена context каскадно прерывает все downstream-вызовы, не давая делать «зомби»-работу.

**В:** Почему не стоит ретраить на каждом уровне стека?
**О:** Ретраи перемножаются: если клиент делает 3 попытки, прокси 3, и SDK 3 — это до 27 запросов на один логический вызов, что многократно усиливает retry storm. Ретрай должен жить на одном уровне (обычно ближе к клиенту или в mesh), остальные — passthrough.

**В:** Стоит ли ретраить ошибку 429?
**О:** Да, но с уважением к `Retry-After`: сервер явно просит притормозить. Ретрай с backoff уместен, но без него можно лишь усугубить rate-limiting. В отличие от 4xx вроде 400/404, которые детерминированы и ретраить их бессмысленно.

## На что копают на senior+
- Понимаешь ли ты, что ретрай — **усилитель нагрузки**, и умеешь ли проектировать защиту от retry storm (budget + breaker + jitter), а не просто «обернуть в for».
- Связываешь ли ретраи с **идемпотентностью и idempotency keys**, разбираешь ли кейс «выполнилось, но ответ потерян».
- Знаешь ли конкретику jitter (формулы full/equal/decorrelated) и вывод исследования AWS, а не «добавим рандом».
- Понимаешь ли **deadline propagation** и взаимодействие per-attempt timeout vs overall deadline.
- Видишь ли проблему **многоуровневых ретраев** и их мультипликативный эффект.
- Можешь ли обосновать, **что именно ретраить** (transient 5xx/timeout/connection reset) и что нет (4xx, DeadlineExceeded).
- Знаешь ли промышленные реализации (gRPC service config, Envoy, Linkerd, cenkalti/backoff) и где ретраи лучше держать — в коде или в mesh.