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 Saga — это способ управлять данными в нескольких сервисах/БД через последовательность **локальных транзакций**, где каждый шаг публикует событие/команду, запускающую следующий шаг. Если шаг падает, выполняется серия **компенсирующих транзакций**, откатывающих эффекты предыдущих шагов **семантически** (а не настоящим rollback). Saga жертвует Isolation из ACID: вы получаете ACD без I. Два стиля координации: **оркестрация** (центральный координатор дёргает участников командами) и **хореография** (участники реагируют на события друг друга, без центра). Главные проблемы: отсутствие изоляции (dirty reads, lost updates), компенсации могут падать (нужны ретраи и идемпотентность), часть шагов невозможно компенсировать. Решается это контрмерами (semantic lock, commutative updates, pessimistic view, reread value, by value) и разделением шагов на **compensatable / pivot / retriable**. ## Теория ### Зачем вообще saga В монолите с одной БД бизнес-операция «создать заказ» — это одна ACID-транзакция: либо всё закоммитилось, либо всё откатилось. В микросервисной архитектуре с database-per-service данные «заказ», «оплата», «склад», «доставка» лежат в разных БД разных сервисов. Распределённой ACID-транзакции поверх них нет (или она неприемлема — см. ниже про 2PC). Saga — это паттерн поддержания **data consistency** между сервисами без распределённых транзакций. Saga = последовательность локальных транзакций T1, T2, ..., Tn. Каждая Ti атомарна в рамках своего сервиса. Координация между Ti — через асинхронные сообщения. Если Tk падает — выполняем компенсации Ck-1, Ck-2, ..., C1 в обратном порядке. ``` Happy path: T1 ── T2 ── T3 ── T4 (все локальные транзакции прошли) Failure на T3, откат: T1 ── T2 ── T3✗ │ │ C1 ◀─ C2 (компенсации в обратном порядке) ``` ### Оркестрация vs хореография Это два способа ответить на вопрос «кто решает, какой шаг следующий». #### Хореография (event-driven, decentralized) Нет центрального координатора. Каждый сервис подписан на события и публикует свои. Saga «двигается» сама собой через цепочку событий. ``` Order Service Payment Service Inventory Service │ │ │ create order │ │ │── OrderCreated ──────▶│ │ │ charge card │ │ │── PaymentDebited ────▶│ │ │ reserve stock │◀───────────────── StockReserved ──────────────│ approve order ``` Плюсы: - Слабая связанность: сервисы не знают про существование оркестратора, только про события. - Нет single point of failure в виде координатора. - Просто для коротких saga (2-3 участника). - Хорошо ложится на event-driven архитектуру, которая часто уже есть. Минусы: - **Логика saga размазана** по всем сервисам — нет одного места, где видно весь flow. Тяжело понять и поддерживать. - **Циклические зависимости** между сервисами через события: A слушает B, B слушает A. - Риск, что сервис подписан на события, которые его не касаются («event coupling»). - Тяжело отлаживать и тестировать: чтобы понять процесс, надо собрать его из подписок в N репозиториях. - Сложно реализовать сложные условные ветвления. #### Оркестрация (central orchestrator, command-driven) Есть отдельный объект/сервис — **Saga Orchestrator** (часто реализуется как state machine / persistent state machine, напр. через outbox + таблицу состояний). Он шлёт **команды** участникам и реагирует на их ответы, продвигая стейт-машину. ``` ┌──────────────────────────┐ │ Order Saga Orchestrator│ │ (state machine) │ └──────────────────────────┘ │ cmd ▲ reply ▼ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Payment │ │Inventory │ │ Delivery │ └──────────┘ └──────────┘ └──────────┘ Flow: Orchestrator → ChargeCard → (ok) → ReserveStock → (ok) → ScheduleDelivery → done на любом fail: Orchestrator запускает компенсации в обратном порядке ``` Плюсы: - **Логика централизована** — весь flow в одном месте, легко читать, тестировать, версионировать. - Участники не знают друг про друга, только выполняют команды → меньше связанности между участниками. - Легко реализовать сложную логику: условия, параллельные ветки, таймауты, ретраи. - Проще observability: состояние saga персистится, видно где «застряла». - Нет цикл. зависимостей. Минусы: - Риск, что бизнес-логика «утечёт» в оркестратор, а участники станут анемичными (антипаттерн «god orchestrator»). - Оркестратор — дополнительный компонент, который надо разрабатывать, деплоить, делать отказоустойчивым (его state machine должна переживать рестарты → persistent saga state). - Потенциальный (но управляемый) single point of coordination. #### Что выбирать | Критерий | Хореография | Оркестрация | |---|---|---| | Кол-во участников | 2-4 | много / сложный flow | | Сложность логики | простая, линейная | условия, ветвления | | Связанность | низкая между сервисами и центром, но высокая event-coupling | низкая между участниками | | Наблюдаемость flow | плохая (размазана) | хорошая (централизована) | | Точка отказа | нет координатора | оркестратор (нужна устойчивость) | Практическое правило: для нетривиальных бизнес-процессов на senior+ почти всегда выбирают **оркестрацию** ради maintainability и observability, держа оркестратор «тонким». ### Компенсирующие транзакции — это semantic rollback, не настоящий rollback Ключевая идея, которую часто проваливают на собеседовании: компенсация **не откатывает** транзакцию в смысле БД (данные уже закоммичены и видны другим). Компенсация — это **новая транзакция**, которая семантически нейтрализует эффект предыдущей. - «Зарезервировали 10 единиц на складе» → компенсация: «снять резерв 10 единиц» (не `ROLLBACK`, а отдельный апдейт). - «Списали $100 с карты» → компенсация: «вернуть $100» (refund — отдельная финансовая операция, может занять дни). - «Отправили email с подтверждением» → компенсировать **невозможно** (письмо уже ушло). Максимум — отправить второе письмо «извините, отмена». Это **non-compensatable** шаг. Из-за этого важна классификация шагов: #### Compensatable / Pivot / Retriable Саги обычно структурируют так, чтобы существовала **pivot transaction** — точка невозврата: - **Compensatable transactions** — шаги в начале saga, которые можно компенсировать. Идут до pivot. - **Pivot transaction** — «go / no-go» точка. После неё saga обязана дойти до конца. Сам pivot — это либо последняя компенсируемая транзакция, либо первая ретраибельная. Пример: списание денег как pivot — после него мы коммитимся к выполнению заказа. - **Retriable transactions** — шаги после pivot, которые **гарантированно завершатся** (повторяются до успеха), и которые **не нужно** компенсировать. Их проектируют так, чтобы они не могли провалиться по бизнес-причине (только по техническим, → ретрай). ``` [ T1 ] [ T2 ] ║ [ Pivot ] ║ [ T3 ] [ T4 ] compensatable ║ точка ║ retriable ║ невозврата ║ (только ретраи, без компенсации) ◀── можно откатить ║ ║ ── только вперёд, до успеха ──▶ ``` Идея: до pivot можно отменить всё; после pivot отмена дороже/невозможна, поэтому всё спроектировано так, чтобы дожать до конца ретраями. ### Когда saga вместо 2PC (two-phase commit) 2PC (XA-транзакции) даёт настоящую распределённую ACID-транзакцию с изоляцией, но: - **Блокирующий протокол**: координатор упал между prepare и commit → участники держат локи на ресурсах неопределённо долго (blocking problem). Это убивает доступность. - Плохо масштабируется, держит локи на время всего round-trip → низкая throughput. - Требует поддержки XA от всех ресурсов; современные брокеры (Kafka), многие NoSQL БД, внешние HTTP-API его **не поддерживают**. - Противоречит автономности сервисов и database-per-service. - По CAP жертвует доступностью. Saga вместо 2PC выбирают, когда: - Участники — разные технологии / внешние API без XA. - Нужна высокая доступность и отсутствие распределённых локов. - Бизнес-процесс длительный (long-running, секунды–дни: ожидание оплаты, доставки). - Допустима eventual consistency и отсутствие изоляции (с применением контрмер). Saga **не подходит** (или нужна особая осторожность), когда нужна строгая изоляция в реальном времени и бизнес не терпит промежуточных несогласованных состояний на коротком окне без контрмер. ### Сложности saga (ACD без I) Saga даёт **Atomicity** (через компенсации), **Consistency** (eventual), **Durability** (локальные транзакции durable), но **НЕ даёт Isolation**. Отсутствие I порождает аномалии — те же, что и при низких уровнях изоляции в СУБД: - **Lost updates** — saga A перезаписывает изменения, сделанные saga B, не прочитав их. - **Dirty reads** — saga B читает данные, записанные saga A до того, как A откатилась компенсацией. - **Fuzzy / non-repeatable reads** — разные шаги одной saga видят разные значения, потому что между ними другая saga изменила данные. Дополнительно: - **Компенсация может упасть.** Сеть, недоступность сервиса, баг. Компенсация — это сетевой вызов, который тоже ненадёжен. → Компенсации должны **ретраиться** до успеха (at-least-once delivery), часто с exponential backoff и DLQ + алертом + ручным вмешательством как последний рубеж. - **Идемпотентность обязательна** и для шагов, и для компенсаций. Из-за at-least-once доставки сообщений один и тот же шаг/компенсация может прийти дважды. Повторный «refund $100» не должен вернуть $200. Реализуют через дедупликацию по message id / idempotency key, проверку текущего состояния перед применением. - **Commutativity компенсаций**: иногда компенсация приходит до того, как пришла исходная команда (out-of-order). Шаги должны корректно обрабатывать и это. ### Countermeasures (контрмеры против отсутствия изоляции) Из работы Chris Richardson / Caitie McCaffrey. Цель — снизить или устранить аномалии без настоящих локов. - **Semantic lock** — приложение помечает запись «флагом» (например `*_PENDING`: `ORDER_PENDING`, `payment = PENDING`), пока saga не завершилась. Compensatable-транзакция ставит флаг, retriable/финальная — снимает. Другие saga, видя флаг, либо ждут, либо отказываются, либо обрабатывают как блокировку прикладного уровня. Самая распространённая контрмера. Требует логики обработки «занятых» записей (фактически прикладной 2PL). - **Commutative updates** — проектировать операции коммутативными, чтобы порядок применения не влиял на результат. Классика: `+100` и `-100` коммутативны. Тогда dirty read/lost update менее опасны: компенсация (`-100`) корректно отменяет (`+100`) независимо от порядка. - **Pessimistic view** — переупорядочить шаги saga так, чтобы минимизировать бизнес-риск от dirty read. Пример: при отмене заказа сначала уменьшить доступный кредит клиента (или не увеличивать лимит), и только потом делать рискованные шаги — чтобы клиент в промежутке не «увёл» средства. - **Reread value** — оптимистическая блокировка: перед апдейтом перечитать запись и проверить, что она не изменилась с момента предыдущего чтения (version / etag). Если изменилась — abort и пересчёт. Предотвращает lost updates. - **By value** — выбирать стратегию управления конкурентностью **динамически по бизнес-риску запроса**. Низкорисковые операции (мелкая сумма) идут через saga с контрмерами; высокорисковые (крупный платёж) — через распределённую транзакцию / 2PC или ручную проверку. Гибрид. ```go // Пример semantic lock + идемпотентность шага компенсации func (s *PaymentService) RefundPayment(ctx context.Context, cmd RefundCmd) error { return s.tx(ctx, func(tx *sql.Tx) error { // идемпотентность: дедуп по saga/idempotency key var alreadyDone bool err := tx.QueryRowContext(ctx, `SELECT EXISTS(SELECT 1 FROM processed_commands WHERE id=$1)`, cmd.IdempotencyKey).Scan(&alreadyDone) if err != nil { return err } if alreadyDone { return nil // уже компенсировали — no-op, но шлём ack } var status string // semantic lock: работаем только если платёж в нужном состоянии err = tx.QueryRowContext(ctx, `SELECT status FROM payments WHERE id=$1 FOR UPDATE`, cmd.PaymentID).Scan(&status) if err != nil { return err } if status != "DEBITED" { // нечего возвращать (out-of-order / уже refunded) — коммутативно безопасно return s.markProcessed(ctx, tx, cmd.IdempotencyKey) } if _, err := tx.ExecContext(ctx, `UPDATE payments SET status='REFUNDED', balance=balance+$2 WHERE id=$1`, cmd.PaymentID, cmd.Amount); err != nil { return err } return s.markProcessed(ctx, tx, cmd.IdempotencyKey) }) } ``` ### Полная ASCII-диаграмма flow с компенсацией ``` CreateOrder Saga (оркестрация) Orchestrator state machine: START │ cmd: CreateOrder(PENDING) [compensatable, semantic lock = PENDING] ▼ ORDER_CREATED ──────fail──▶ reject locally, END(FAILED) │ cmd: ReserveStock [compensatable] ▼ STOCK_RESERVED ─────fail──▶ C: CancelOrder ─▶ END(FAILED) │ cmd: ChargePayment ═══ PIVOT ═══ [после успеха — только вперёд] ▼ PAYMENT_DONE ───fail──▶ C: ReleaseStock ─▶ C: CancelOrder ─▶ END(FAILED) │ cmd: ScheduleDelivery [retriable: ретраим до успеха] ▼ DELIVERY_SCHEDULED │ cmd: ApproveOrder (status=APPROVED) [retriable: снимаем semantic lock] ▼ END(SUCCESS) Каждая стрелка вниз = команда + ожидание reply. Любой reply=fail ДО pivot → запуск цепочки компенсаций C в обратном порядке. Любой fail ПОСЛЕ pivot → НЕ компенсируем, а ретраим шаг до успеха. ``` ## Подводные камни / gotchas - **Компенсация — это не `ROLLBACK`.** Данные уже видны другим. Думать в терминах «обратной бизнес-операции», а не отката БД. - **Забыли про идемпотентность.** At-least-once доставка + ретраи → двойное списание/начисление. Нужен idempotency key и дедупликация на каждом шаге И каждой компенсации. - **Компенсация падает и нет ретрая/DLQ.** Saga зависает в неконсистентном состоянии. Нужны: ретраи с backoff, DLQ, алерты, ручной runbook. Компенсации проектировать максимально надёжными (locally retriable). - **Non-compensatable шаги выполнены слишком рано.** Отправка email / вызов внешнего необратимого API нужно делать **после pivot** (в retriable-зоне) или вообще в самом конце. - **Out-of-order сообщения.** Компенсация может прийти раньше команды. Шаги должны быть коммутативны или проверять состояние. - **Игнор отсутствия изоляции.** Dirty read привёл к тому, что другой процесс принял решение по «грязным» данным, которые потом откатились. Применять semantic lock / pessimistic view. - **God orchestrator.** Вся бизнес-логика уехала в оркестратор, сервисы стали CRUD-обёртками. Оркестратор должен координировать, а не содержать всю доменную логику. - **Saga state не персистится.** Оркестратор перезапустился — забыл, где была saga. State machine обязана быть durable (таблица + outbox). - **Двойная публикация (dual write).** Закоммитили в БД и упали до публикации события (или наоборот). Использовать **transactional outbox** + CDC/poller, чтобы запись состояния и публикация события были атомарны. - **Тайм-ауты не обрабатываются.** Участник не ответил вообще. Нужны таймауты в стейт-машине, которые тоже запускают компенсацию. ## Вопросы на собеседовании **В:** Чем компенсирующая транзакция отличается от rollback в БД? **О:** Rollback откатывает незакоммиченную транзакцию, и её эффекты никогда не были видны другим. Компенсация — это новая, отдельная транзакция, которая семантически нейтрализует уже **закоммиченный и видимый** эффект (резерв снять, деньги вернуть). Поэтому она не всегда возможна (email не вернуть), может сама упасть и требует идемпотентности и ретраев. **В:** Saga vs 2PC — когда что? **О:** 2PC даёт настоящую ACID-изоляцию, но это блокирующий протокол (координатор упал → локи висят), плохо масштабируется и требует XA-поддержки от всех участников. Saga выбирают, когда участники гетерогенны/внешние API без XA, нужна высокая доступность без распределённых локов, процесс длительный, и допустима eventual consistency с контрмерами вместо изоляции. **В:** Оркестрация или хореография для процесса из 6 сервисов с условными ветвлениями? **О:** Оркестрация. Хореография при таком масштабе размазывает логику по всем сервисам, плодит event-coupling и циклические зависимости, делает невозможным понимание и отладку flow. Оркестратор централизует логику, даёт наблюдаемость и легко выражает ветвления. Держать его тонким, чтобы не превратить в god-объект. **В:** Saga даёт ACID? **О:** Даёт ACD, но **не Isolation**. Atomicity — через компенсации, Consistency — eventual, Durability — за счёт локальных durable-транзакций. Отсутствие изоляции порождает аномалии: dirty reads, lost updates, non-repeatable reads. Их закрывают контрмерами (semantic lock, commutative updates, pessimistic view, reread value, by value). **В:** Что такое pivot transaction? **О:** Точка невозврата в saga. Шаги до pivot — compensatable (можно откатить). Pivot — go/no-go решение. Шаги после pivot — retriable: они гарантированно завершаются (ретраятся до успеха) и не компенсируются. Это структурирует saga так, чтобы необратимые/дорогие шаги были после точки, начиная с которой мы коммитимся довести процесс до конца. **В:** Почему идемпотентность обязательна? **О:** Доставка сообщений at-least-once, плюс ретраи компенсаций → один шаг или компенсация может прийти несколько раз. Без идемпотентности это двойное списание, двойной refund, двойной резерв. Реализуют через idempotency key + таблицу обработанных команд / проверку текущего состояния перед применением. **В:** Что делать, если компенсация падает? **О:** Компенсация — сетевой вызов и тоже ненадёжна. Её нужно ретраить (at-least-once, exponential backoff), и она должна быть идемпотентной. На исчерпание ретраев — DLQ + алерт + runbook для ручного разбора. Сами компенсации проектируют максимально безотказными (минимум зависимостей, locally retriable), и ставят необратимые шаги после pivot, чтобы их не приходилось компенсировать. **В:** Что такое semantic lock и зачем он? **О:** Прикладной флаг на записи (`PENDING`), который ставит compensatable-транзакция и снимает финальная. Пока флаг стоит, другие saga либо ждут, либо отвергаются, либо обрабатывают как занято. Это контрмера против отсутствия изоляции — фактически прикладной двухфазный лок, предотвращающий dirty read/lost update на время выполнения saga. **В:** Как избежать dual write проблемы (БД + брокер)? **О:** Transactional outbox: в той же локальной транзакции, что и изменение состояния, пишем событие в таблицу outbox. Отдельный poller/CDC читает outbox и публикует в брокер с at-least-once. Так запись и «намерение опубликовать» атомарны; потребители дедуплицируют по message id. ## На что копают на senior+ - Чёткое понимание, что компенсация — **semantic rollback**, и какие шаги в принципе **не компенсируемы**, как это влияет на порядок шагов и на pivot. - Классификация шагов на compensatable / pivot / retriable и умение объяснить, почему это снижает сложность обработки сбоев. - Глубина по отсутствию изоляции: назвать конкретные аномалии (dirty read, lost update, non-repeatable read) и сопоставить им конкретные контрмеры. - Идемпотентность и at-least-once на уровне реализации: idempotency key, дедупликация, обработка out-of-order и повторных компенсаций. - Transactional outbox / inbox как решение dual-write, понимание CDC. - Durable saga state machine, обработка таймаутов и зависших saga, observability и runbook на упавшие компенсации. - Осознанный выбор оркестрация vs хореография по конкретному кейсу с аргументами, а не «по вкусу». - Понимание границ применимости: где saga неприемлема и нужна синхронная согласованность/2PC или by-value-гибрид (крупные деньги, критичный инвентарь).