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 - **Идемпотентность** — повторное выполнение операции с теми же параметрами даёт тот же результат и те же побочные эффекты, что и однократное. `f(f(x)) == f(x)` на уровне состояния системы. - Нужна потому, что сеть ненадёжна: клиент не знает, дошёл ли запрос. Любая система с **ретраями** и доставкой **at-least-once** обязана быть идемпотентной, иначе дубли (двойные списания, двойные заказы). - HTTP: `GET`, `PUT`, `DELETE`, `HEAD`, `OPTIONS` идемпотентны *по семантике спецификации*; `POST` и `PATCH` — нет. Спецификация не гарантирует реализацию. - Практика для не-идемпотентных операций: **idempotency key** — клиент генерирует уникальный ключ, сервер хранит `(key → результат, статус)` и при повторе отдаёт сохранённый ответ вместо повторного выполнения. - Самое сложное — **конкурентные запросы с одним ключом** (in-flight). Решается через unique constraint или distributed lock + конечный автомат статусов `processing → completed/failed`. - На уровне БД идемпотентность достигается через `UPSERT`, `INSERT ... ON CONFLICT`, unique constraints, `INSERT ... WHERE NOT EXISTS`. ## Теория ### Зачем нужна идемпотентность В распределённой системе невозможно отличить «запрос не дошёл» от «ответ не дошёл». Это фундаментальная проблема **two generals**: клиент отправил `POST /payments`, получил таймаут. Что произошло? ``` Клиент Сервер | POST /payments ---------> | списал $100 | | отправил 200 OK | <-- X (ответ потерян) | | таймаут, ретрай | | POST /payments ---------> | списал ещё $100 ← ДУБЛЬ ``` Без идемпотентности безопасный ретрай невозможен. А ретраи неизбежны: - **At-least-once delivery** — основная гарантия большинства брокеров (Kafka, SQS, RabbitMQ с ack). Брокер скорее доставит дважды, чем потеряет. - Ретраи на уровне HTTP-клиентов, service mesh (Envoy/Istio), gRPC. - Перезапуск воркеров после краша до коммита оффсета. > Exactly-once в общем случае недостижимо на транспортном уровне. Практический exactly-once = **at-least-once delivery + идемпотентная обработка (дедупликация)**. ### Идемпотентность vs безопасность (safety) Не путать два свойства HTTP: - **Safe** — не меняет состояние (read-only): `GET`, `HEAD`, `OPTIONS`. - **Idempotent** — повтор не меняет результат относительно однократного выполнения. Все safe-методы идемпотентны, но не наоборот. | Метод | Safe | Idempotent | Комментарий | |---------|------|------------|-------------| | GET | да | да | только чтение | | HEAD | да | да | как GET без тела | | OPTIONS | да | да | метаданные | | PUT | нет | **да** | полная замена ресурса: `PUT /users/1 {name:"A"}` сколько угодно раз → один результат | | DELETE | нет | **да** | удаление уже удалённого — то же состояние (хотя статус может отличаться 200 vs 404) | | POST | нет | **нет** | создание ресурса: каждый вызов создаёт новый | | PATCH | нет | **нет** | частичное изменение, не обязано быть идемпотентным (напр. `{balance: balance+10}`) | Тонкость с `DELETE`: операция идемпотентна по *состоянию* (ресурса нет), но HTTP-статусы повторов могут различаться (первый — `204`, второй — `404`). Это нормально: идемпотентность — про состояние системы, а не про байт-в-байт идентичность ответа. Тонкость с `PUT`: идемпотентен, только если payload не содержит относительных операций. `PUT {counter: 5}` — идемпотентен, а `PUT` с серверным `updated_at = now()` строго говоря меняет ответ, но семантически считается идемпотентным. ### Idempotency keys: паттерн для POST/PATCH Поскольку `POST` неидемпотентен по природе, индустрия (Stripe, PayPal, GitHub) ввела **idempotency key** — заголовок, который клиент генерирует и переиспользует при ретраях: ``` POST /v1/charges Idempotency-Key: 7f8a9b3c-1d2e-4f5a-8b6c-9d0e1f2a3b4c ``` Контракт: 1. Клиент генерирует ключ **один раз** на логическую операцию (UUIDv4) и шлёт его при всех ретраях этого запроса. 2. Сервер: если ключ виден впервые — выполняет операцию, сохраняет результат под ключом. 3. Если ключ уже виден — возвращает **сохранённый результат** без повторного выполнения. Что хранить: - `idempotency_key` (PK / unique) - `status` (`processing` / `completed` / `failed`) - `response_code`, `response_body` (снапшот ответа) - `request_fingerprint` (хэш тела запроса — защита от reuse ключа с другим payload) - `created_at`, `expires_at` (TTL) ``` ┌──────────────────────────────────────────────────────────┐ │ idempotency_keys │ ├──────────────┬──────────┬──────────┬──────────┬──────────┤ │ key (UNIQUE) │ status │ resp_code│ resp_body│ fp │ ├──────────────┼──────────┼──────────┼──────────┼──────────┤ │ 7f8a... │ completed│ 200 │ {...} │ a1b2... │ │ c4d5... │ processing│ NULL │ NULL │ e6f7... │ └──────────────┴──────────┴──────────┴──────────┴──────────┘ ``` ### TTL для ключей Ключи нельзя хранить вечно. TTL = окно, в течение которого клиент может ретраить (Stripe — 24 часа). После TTL ключ можно переиспользовать. Реализация: - Redis: `SET key ... EX 86400` — автоматическая эвикция. - Postgres: колонка `expires_at` + периодический cleanup-джоб (`DELETE WHERE expires_at < now()`) или partitioning по времени. Компромисс: слишком короткий TTL → ретрай после TTL создаст дубль; слишком длинный → разрастание хранилища. ### Race condition: конкурентные запросы с одним ключом (главная проблема) Самый частый баг наивной реализации: ```go // ПЛОХО: проверка-затем-действие (check-then-act) — TOCTOU existing, _ := store.Get(key) if existing != nil { return existing.Response // отдаём сохранённое } result := doExpensiveOperation() // <-- два запроса попадут сюда одновременно store.Save(key, result) ``` Два параллельных запроса с одним ключом (клиент агрессивно ретраит, или балансировщик задублировал) оба проходят `Get == nil` → оба выполняют операцию. Дубль. **Решение 1 — unique constraint + статус-машина (рекомендуемое).** Атомарно вставляем строку со статусом `processing`. Кто проиграл гонку на insert — получает конфликт и ждёт/опрашивает результат победителя. ``` Запрос A: INSERT key, status=processing → OK, выполняет операцию Запрос B: INSERT key, status=processing → UNIQUE VIOLATION → читает строку, видит processing → возвращает 409 Conflict / ждёт completed Запрос A: UPDATE key SET status=completed, response=... ``` **Решение 2 — distributed lock** (Redis `SETNX` / `SET NX PX`, Redlock). Захватываем лок на ключ перед выполнением. Минус: лок может протухнуть/зависнуть, нужен fencing token; сложнее, чем unique constraint. Как отвечать на in-flight дубль: - **409 Conflict** «запрос с этим ключом ещё обрабатывается, повторите позже» — простой и честный вариант. - Или **дождаться** завершения первого (polling статуса с backoff) и вернуть его результат — лучше для UX, но дольше держит соединение. Защита от reuse ключа с другим телом: при конфликте сравнить `request_fingerprint`. Если совпадает — дедуп. Если различается — `422 Unprocessable Entity` «ключ уже использован с другими параметрами» (защита от ошибок клиента). ### Идемпотентность на уровне БД Часто идемпотентность дешевле обеспечить в самой записи, без отдельной таблицы ключей. **UPSERT** — повторная вставка не создаёт дубль: ```sql INSERT INTO orders (id, user_id, amount) VALUES ('order-123', 42, 100) ON CONFLICT (id) DO NOTHING; -- идемпотентное создание -- или DO UPDATE SET amount = EXCLUDED.amount; -- идемпотентная замена ``` **Unique constraint как дедупликатор.** Если у бизнес-сущности есть естественный ключ (`payment_external_id`, `message_id` из брокера) — повесить unique-индекс. Повторная вставка падает с ошибкой → ловим её как «уже обработано». ```sql CREATE UNIQUE INDEX idx_dedup ON processed_messages (message_id); -- обработчик Kafka: INSERT INTO processed_messages (message_id, ...) VALUES (...) ON CONFLICT (message_id) DO NOTHING; -- если 0 строк затронуто → дубль, скипаем бизнес-логику ``` **Условный UPDATE** для переходов состояний (защита от повтора и от гонок): ```sql UPDATE orders SET status = 'paid' WHERE id = 'order-123' AND status = 'pending'; -- RowsAffected == 0 → уже оплачен (или нет такого) → повтор безопасен ``` **Транзакционность.** Бизнес-операция и запись ключа/дедуп-маркера должны коммититься в **одной транзакции**. Иначе: операция выполнилась, а маркер не записался (или наоборот) → следующий ретрай создаст дубль. Для брокеров это паттерн **inbox** (дедуп входящих) и **outbox** (надёжная публикация исходящих). ### Пример: idempotency middleware на Go Вариант с Postgres (надёжное хранилище + транзакционность с бизнес-логикой). Ключевая идея — атомарный `INSERT ... ON CONFLICT` для захвата ключа. ```go package idempotency import ( "bytes" "context" "crypto/sha256" "database/sql" "encoding/hex" "encoding/json" "errors" "io" "net/http" "time" ) type record struct { Status string // "processing" | "completed" RespCode int RespBody []byte Fingerprint string } type Store struct{ db *sql.DB } // tryAcquire атомарно пытается застолбить ключ в статусе processing. // Возвращает (rec=nil, acquired=true) — мы первые, выполняем операцию. // Возвращает (rec!=nil, acquired=false) — ключ уже есть, отдаём/ждём. func (s *Store) tryAcquire(ctx context.Context, key, fp string, ttl time.Duration) (*record, bool, error) { res, err := s.db.ExecContext(ctx, ` INSERT INTO idempotency_keys (key, status, fingerprint, expires_at) VALUES ($1, 'processing', $2, $3) ON CONFLICT (key) DO NOTHING`, key, fp, time.Now().Add(ttl)) if err != nil { return nil, false, err } if n, _ := res.RowsAffected(); n == 1 { return nil, true, nil // мы захватили ключ } // конфликт — читаем существующую запись var r record err = s.db.QueryRowContext(ctx, ` SELECT status, COALESCE(resp_code,0), COALESCE(resp_body,''::bytea), fingerprint FROM idempotency_keys WHERE key = $1`, key). Scan(&r.Status, &r.RespCode, &r.RespBody, &r.Fingerprint) if err != nil { return nil, false, err } return &r, false, nil } func (s *Store) complete(ctx context.Context, key string, code int, body []byte) error { _, err := s.db.ExecContext(ctx, ` UPDATE idempotency_keys SET status='completed', resp_code=$2, resp_body=$3 WHERE key=$1`, key, code, body) return err } // Middleware применяет идемпотентность только к мутирующим методам. func (s *Store) Middleware(ttl time.Duration) func(http.Handler) http.Handler { return func(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { key := r.Header.Get("Idempotency-Key") if key == "" || (r.Method != http.MethodPost && r.Method != http.MethodPatch) { next.ServeHTTP(w, r) // ключ не требуется return } body, _ := io.ReadAll(r.Body) r.Body = io.NopCloser(bytes.NewReader(body)) fp := fingerprint(r.Method, r.URL.Path, body) rec, acquired, err := s.tryAcquire(r.Context(), key, fp, ttl) if err != nil { http.Error(w, "idempotency store error", http.StatusInternalServerError) return } if !acquired { // ключ уже существует if rec.Fingerprint != fp { http.Error(w, "key reused with different payload", http.StatusUnprocessableEntity) return } switch rec.Status { case "completed": replay(w, rec) // отдаём сохранённый ответ case "processing": // in-flight: первый запрос ещё работает w.Header().Set("Retry-After", "1") http.Error(w, "request in progress", http.StatusConflict) } return } // Мы захватили ключ — выполняем хендлер, перехватывая ответ. rw := &capture{ResponseWriter: w, code: http.StatusOK} next.ServeHTTP(rw, r) // Сохраняем результат. В проде: бизнес-логика + complete() // должны быть в ОДНОЙ транзакции, чтобы избежать рассинхрона. if err := s.complete(r.Context(), key, rw.code, rw.buf.Bytes()); err != nil { // логируем; ключ останется processing до TTL — следующий ретрай получит 409 return } }) } } func fingerprint(method, path string, body []byte) string { h := sha256.New() h.Write([]byte(method + "\n" + path + "\n")) h.Write(body) return hex.EncodeToString(h.Sum(nil)) } func replay(w http.ResponseWriter, rec *record) { w.Header().Set("Idempotent-Replayed", "true") w.WriteHeader(rec.RespCode) _, _ = w.Write(rec.RespBody) } // capture перехватывает код и тело ответа для сохранения. type capture struct { http.ResponseWriter code int buf bytes.Buffer } func (c *capture) WriteHeader(code int) { c.code = code; c.ResponseWriter.WriteHeader(code) } func (c *capture) Write(b []byte) (int, error) { c.buf.Write(b) return c.ResponseWriter.Write(b) } var _ = json.Marshal var _ = errors.Is ``` Вариант с Redis (быстрее, но без транзакции с бизнес-БД — годится, когда сама операция уже идемпотентна на уровне записи): ```go // Атомарный захват через SET NX. Значение — маркер processing. ok, err := rdb.SetNX(ctx, "idem:"+key, "processing", ttl).Result() if err != nil { /* ... */ } if !ok { // ключ уже есть → читаем сохранённый ответ или отдаём 409 если processing val, _ := rdb.Get(ctx, "idem:"+key).Result() // ...распарсить и отдать... return } // мы первые — выполняем, потом перезаписываем маркер на сериализованный ответ defer rdb.Set(ctx, "idem:"+key, serializedResponse, ttl) ``` > Redis-вариант менее надёжен: если воркер упал между `SetNX` и записью ответа, ключ застрянет в `processing` до TTL. Для денежных операций предпочтительнее Postgres с транзакцией бизнес-логика+ключ. ## Подводные камни / gotchas - **Check-then-act вместо атомарного insert.** Самый частый баг — `Get(); if nil { do() }`. Гонка → дубли. Всегда атомарный `INSERT ON CONFLICT` / `SETNX`. - **Ключ не транзакционен с бизнес-логикой.** Если операция закоммитилась, а ключ — нет (или наоборот), система рассинхронизируется. Один коммит на оба изменения. - **Застрявший `processing`.** Воркер упал после захвата ключа, не дойдя до `completed`. Без TTL/таймаута ключ навсегда блокирует ретраи. Нужен TTL + механизм перевода протухшего `processing` в доступное состояние. - **Сервер генерирует ключ.** Тогда при ретрае ключ другой → дедуп не работает. Ключ обязан генерировать **клиент** (или прокси на входе, но стабильно для ретраев). - **Reuse ключа с другим телом.** Без проверки fingerprint клиент по ошибке отправит другой payload под старым ключом и получит чужой ответ. Сравнивать хэш запроса. - **Идемпотентность только на API, но не в обработчике сообщений.** HTTP защитили, а consumer Kafka при ребалансе обрабатывает сообщение дважды. Дедуп нужен на каждой at-least-once границе. - **TTL короче окна ретраев клиента.** Клиент ретраит через 25 часов, ключ протух за 24 → дубль. TTL ≥ максимального горизонта ретраев. - **«DELETE идемпотентен, значит ответ одинаков».** Нет: состояние одинаково, а статусы (204 → 404) могут различаться. Не завязывайте логику на идентичность ответа. - **Неидемпотентный PATCH/POST приняли за идемпотентный** и включили агрессивные ретраи в mesh без ключей → дубли заказов. - **Идемпотентность ≠ конкурентная корректность.** Два *разных* запроса (разные ключи) на один ресурс всё равно требуют оптимистичных/пессимистичных блокировок (версии, `SELECT FOR UPDATE`). ## Вопросы на собеседовании **В:** В чём разница между safe и idempotent методами HTTP? **О:** Safe — не меняет состояние сервера (read-only: GET, HEAD, OPTIONS). Idempotent — повтор не меняет результат относительно однократного выполнения. Все safe идемпотентны, но не наоборот: PUT и DELETE меняют состояние, но идемпотентны. **В:** Почему POST не идемпотентен, а PUT — да? **О:** POST создаёт новый ресурс при каждом вызове (N вызовов → N ресурсов). PUT — полная замена ресурса по известному URI: N одинаковых PUT приводят к тому же состоянию, что и один. PATCH тоже неидемпотентен, если содержит относительные операции (`balance += 10`). **В:** Зачем вообще нужна идемпотентность, если можно просто не ретраить? **О:** Сеть ненадёжна, и при таймауте клиент не знает, дошёл ли запрос. Большинство брокеров и mesh дают at-least-once доставку — дубли неизбежны. Exactly-once на транспорте недостижим; практически он строится как at-least-once delivery + идемпотентная обработка. **В:** Как реализовать idempotency key и что хранить? **О:** Клиент генерирует уникальный ключ (UUID) и шлёт его при всех ретраях операции. Сервер хранит `key → (status, response_code, response_body, request_fingerprint, expires_at)`. Первый запрос выполняет операцию и сохраняет ответ; повторы получают сохранённый ответ без повторного выполнения. **В:** Что произойдёт при двух одновременных запросах с одним ключом и как это решить? **О:** При наивной check-then-act реализации оба пройдут проверку «ключа нет» и оба выполнят операцию — дубль. Решение: атомарный `INSERT ... ON CONFLICT DO NOTHING` со статусом `processing`. Победитель выполняет операцию, проигравший получает unique violation и возвращает 409 (или ждёт результат). Альтернатива — distributed lock (SETNX/Redlock с fencing token). **В:** Как обеспечить идемпотентность на уровне БД без отдельной таблицы ключей? **О:** UPSERT (`INSERT ... ON CONFLICT DO NOTHING/UPDATE`), unique constraint на естественном ключе (повторная вставка падает → ловим как «уже обработано»), условный UPDATE с проверкой текущего статуса (`WHERE status='pending'`, смотрим RowsAffected). **В:** Почему запись idempotency-ключа должна быть в одной транзакции с бизнес-логикой? **О:** Иначе возможен рассинхрон: операция закоммитилась, а ключ нет (ретрай повторит операцию → дубль) или ключ записан, а операция откатилась (ретрай вернёт «успех» по несуществующей операции). Атомарность обоих изменений гарантирует консистентность. **В:** Что такое inbox/outbox и как они связаны с идемпотентностью? **О:** Outbox — запись исходящего события в ту же транзакцию, что и бизнес-изменение, с последующей надёжной публикацией (решает «опубликовали, но не закоммитили»). Inbox — дедупликация входящих сообщений по `message_id` через unique constraint (идемпотентная обработка at-least-once потока). **В:** Как выбрать TTL для ключей? **О:** TTL должен покрывать максимальный горизонт ретраев клиента. Слишком короткий → ретрай после истечения создаст дубль; слишком длинный → разрастание хранилища. Stripe использует 24 часа. Реализация: Redis EXPIRE или Postgres `expires_at` + cleanup-джоб/партиционирование. ## На что копают на senior+ - **Глубина с race conditions.** Senior должен сразу назвать check-then-act как баг и предложить атомарный insert/SETNX, а не «проверю в начале хендлера». Бонус — обсуждение fencing token при Redis-локах и проблем Redlock. - **Транзакционные границы.** Понимание, что ключ и бизнес-операция должны коммититься вместе, и знание паттернов inbox/outbox для брокеров. - **Exactly-once как миф.** Умение объяснить, что exactly-once delivery невозможен, и что реально достигается дедупликацией поверх at-least-once. - **In-flight обработка.** Что делать с конкурентным дублем: 409 vs ожидание результата, trade-offs по UX и удержанию соединений; восстановление застрявшего `processing`. - **Идемпотентность на всех границах.** Не только HTTP API, но и consumer'ы брокеров, retry в gRPC/mesh, перезапуски воркеров. - **Связь с конкурентным доступом.** Чёткое разделение: идемпотентность защищает от повтора *одного* запроса, но не заменяет оптимистичные блокировки/версионирование для конкурентных *разных* запросов. - **Выбор хранилища.** Когда Redis (скорость, TTL из коробки, но нет транзакции с бизнес-БД), когда Postgres (надёжность, транзакционность, дороже). Для денег — почти всегда транзакционная БД.