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/ > Модуль: System Design · Уровень: Senior ## TL;DR Платёжный сервис — это система, где **корректность важнее доступности**, а потеря или дублирование денег недопустимы. Три кита: 1. **Идемпотентность** — клиент шлёт `Idempotency-Key`, сервер гарантирует, что повтор запроса (ретрай, таймаут, двойной клик) не спишет деньги дважды. Реализуется через уникальный индекс в БД. 2. **Double-entry ledger** — деньги не «хранятся» как баланс, а выводятся из неизменяемого (append-only) журнала проводок debit/credit, где сумма всех проводок транзакции равна нулю. 3. **Transactional outbox + CDC** — события («платёж проведён») публикуются в брокер строго на основе закоммиченного состояния БД, что даёт *exactly-once effect* поверх *at-least-once delivery* брокера. «Exactly-once деньги» — это не магия брокера, а **at-least-once доставка + идемпотентные обработчики**. Деньги всегда в целочисленных minor units (копейки/центы), никогда во `float`. ## Требования ### Функциональные - Приём платежа: списание с источника (карта/счёт), зачисление получателю. - Авторизация (hold) и последующий capture/void; частичный capture. - Возвраты (refund), частичные возвраты, чарджбэки. - Идемпотентный API создания платежа. - Интеграция с внешними PSP (Stripe, Adyen, локальные банки-эквайеры) через адаптеры. - Обработка асинхронных webhook от PSP (статус платежа меняется вне нашего запроса). - Reconciliation: ежедневная сверка нашего ledger с выписками провайдеров. - Аудит: кто, когда, что, с какого IP; неизменяемая история. ### Нефункциональные (деньги — особый случай) - **Consistency**: строгая. Баланс никогда не должен «уехать». Для одного аккаунта — линеаризуемость. Жертвуем доступностью (CP в CAP) для критичного пути списания. - **Durability**: после ответа `200 OK` платёж не теряется *никогда*. `fsync`, репликация с `synchronous_commit`, RPO = 0 для ledger. - **Auditability**: ledger append-only, immutable. Любую запись можно проследить. Хранение 7+ лет (регуляторика). - **Регуляторика / PCI DSS**: мы не храним PAN (номер карты), CVV — никогда. Используем токенизацию на стороне PSP. Если касаемся карточных данных — это PCI DSS Level 1 со всеми вытекающими (сегментация сети, шифрование at-rest/in-transit, аудит доступа). Лучшая стратегия — **минимизировать scope**: пусть карту видит только PSP, мы храним только их `payment_method_token`. - **Latency**: p99 синхронной авторизации < 1–2 с (включая round-trip до PSP, который и есть боттлнек). Внутренняя обработка ledger — единицы мс. - **Availability**: 99.99% для приёма платежей. Но при выборе consistency vs availability на конфликте — выбираем consistency (лучше отказать в платеже, чем провести его дважды). ## Оценки нагрузки Возьмём средний платёжный шлюз: - **Объём**: 10M транзакций/день ≈ 116 TPS в среднем. - **Пики**: x10 в Black Friday / распродажи ≈ 1160 TPS. Закладываем headroom до ~3000 TPS. - **Чтения**: статусы, история — соотношение read:write ~ 10:1, значит ~1000–1200 QPS чтения в среднем. ### Storage (ledger за годы) Каждая бизнес-транзакция = минимум 2 проводки (double-entry), часто 4 (с комиссиями). Запись проводки ~ 300 байт. - 10M tx/day × 4 проводки × 300 B ≈ **12 GB/день** сырых проводок. - За год: ~4.4 TB. За 7 лет (регуляторное хранение): **~30 TB** только проводки. - Плюс audit log, webhook payloads, idempotency-записи — ещё столько же. - Итого порядок: **60–80 TB** на горизонте хранения. Горячие данные (последние 90 дней) — ~1 TB, держим в основной OLTP БД; холодные — архив (S3/cold storage) + OLAP для аналитики. ### Бюджеты - p99 внутреннего pipeline (без PSP): < 50 мс. - p99 с PSP: ограничен провайдером, 500–2000 мс. Поэтому capture часто делается асинхронно. ## Архитектура ``` Idempotency-Key │ ┌────────┐ HTTPS ┌─────▼──────────┐ │ Client ├──────────►│ Payment API │ (валидация, idempotency check) └────────┘ │ (stateless) │ ▲ └──────┬─────────┘ │ webhook / │ один ACID-коммит: │ status poll │ ledger + outbox + idempotency │ ┌──────▼───────────────────────────┐ │ │ Ledger DB (Postgres) │ │ │ ┌─────────┐ ┌──────┐ ┌────────┐ │ │ │ │ ledger │ │outbox│ │idempot.│ │ │ │ │(append) │ │ table│ │ keys │ │ │ │ └─────────┘ └──┬───┘ └────────┘ │ │ └─────────────────┼────────────────┘ │ │ CDC (Debezium / logical decoding) │ ┌──────▼──────┐ │ │ Kafka / bus │ (at-least-once) │ └──────┬──────┘ │ ┌────────────────────┼──────────────────┐ │ ┌──────▼──────┐ ┌───────▼────────┐ ┌──────▼───────┐ └─────┤ PSP Adapter │◄────►│ Notifier / │ │ Reconciliation│ │ (Stripe/...) │ PSP │ Webhooks out │ │ Worker │ └──────┬───────┘ └────────────────┘ └──────┬───────┘ │ HTTPS │ daily ┌──────▼───────┐ ┌───────▼───────┐ │ External │ │ PSP settlement│ │ PSP / Bank │─────── settlement file ─►│ report │ └──────────────┘ └───────────────┘ ``` ### Компоненты - **Payment API** — stateless, горизонтально масштабируется за LB. Проверяет idempotency-key, валидирует, открывает транзакцию. - **Ledger DB** — источник истины. Postgres (или Spanner/CockroachDB для гео-распределения). Содержит таблицы `ledger_entries` (immutable), `accounts` (баланс/проекция), `outbox`, `idempotency_keys`. Всё критичное пишется одним ACID-коммитом. - **Outbox + CDC** — события в `outbox` пишутся в той же транзакции, что и ledger; отдельный процессор (CDC через logical decoding / Debezium, либо poller) читает outbox и публикует в Kafka. Гарантия: событие публикуется тогда и только тогда, когда транзакция закоммитилась. - **PSP Adapter** — изолирует специфику каждого провайдера за единым интерфейсом. Отвечает за retry, circuit breaker, маппинг ошибок, идемпотентность на стороне PSP (передаём свой ключ в их API). - **Webhook handler** — принимает асинхронные уведомления от PSP (charge succeeded/failed). Идемпотентен: один и тот же webhook может прийти несколько раз. - **Reconciliation Worker** — ежедневно тянет settlement-файлы PSP и сверяет с ledger; расхождения → алерт/тикет. ## Ключевые решения и trade-offs ### 1. Идемпотентность через Idempotency-Key + уникальный индекс Клиент генерирует ключ (UUID) и шлёт его в заголовке. Сервер атомарно «застолбляет» ключ. Если ключ уже есть с завершённым ответом — возвращаем сохранённый ответ, не выполняя операцию повторно. ```sql CREATE TABLE idempotency_keys ( key TEXT PRIMARY KEY, request_hash TEXT NOT NULL, -- хэш тела запроса status TEXT NOT NULL, -- 'in_progress' | 'completed' response_code INT, response_body JSONB, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), locked_until TIMESTAMPTZ -- защита от висящих in_progress ); ``` ```go type IdempotencyResult struct { Replayed bool Code int Body []byte } // reserve пытается застолбить ключ. Если ключ уже есть — отдаёт сохранённый // результат (replay) либо сигналит, что запрос ещё в работе (конфликт). func (s *Store) Reserve(ctx context.Context, key, reqHash string) (*IdempotencyResult, error) { var status, gotHash string var code sql.NullInt32 var body []byte err := s.db.QueryRowContext(ctx, ` INSERT INTO idempotency_keys (key, request_hash, status) VALUES ($1, $2, 'in_progress') ON CONFLICT (key) DO UPDATE SET key = idempotency_keys.key -- no-op, чтобы RETURNING сработал RETURNING status, request_hash, response_code, response_body `, key, reqHash).Scan(&status, &gotHash, &code, &body) if err != nil { return nil, err } // Тот же ключ, но другое тело запроса — клиент переиспользовал ключ. Ошибка. if gotHash != reqHash { return nil, ErrIdempotencyKeyReuse // -> 422 } switch status { case "completed": return &IdempotencyResult{Replayed: true, Code: int(code.Int32), Body: body}, nil case "in_progress": // Параллельный запрос с тем же ключом ещё выполняется. return nil, ErrRequestInFlight // -> 409, клиент ретраит позже } return nil, nil // мы первые — выполняем операцию } ``` Ключевые тонкости: - Проверяем **request_hash**: если ключ тот же, а тело отличается — это ошибка клиента (`422`), а не replay. - Состояние `in_progress` защищает от гонки двух параллельных ретраев. Зависший `in_progress` чистим по `locked_until` (TTL). - TTL ключей: 24–72 часа достаточно для ретраев; вечно хранить не нужно. ### 2. Double-entry ledger (immutable, append-only) Каждая транзакция = набор проводок, сумма которых = 0 (закон сохранения денег). Баланс счёта = `SUM(entries)` или материализованная проекция. ```sql CREATE TABLE ledger_entries ( id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, txn_id UUID NOT NULL, -- группирует проводки одной операции account_id BIGINT NOT NULL, direction SMALLINT NOT NULL, -- +1 debit / -1 credit amount BIGINT NOT NULL, -- minor units, ВСЕГДА > 0 currency CHAR(3) NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() -- НИКАКИХ UPDATE/DELETE. Только INSERT. ); -- инвариант: для каждого txn_id SUM(direction * amount) = 0 (на валюту) ``` Правила: - **Append-only**: ошибку исправляют не правкой, а *компенсирующей проводкой* (reversal). История неприкосновенна — это и есть аудит. - **Никаких float**: `amount BIGINT` в minor units, либо `NUMERIC` для валют с нестандартной дробностью. `float64` теряет точность: `0.1 + 0.2 != 0.3`. ```go // Деньги — отдельный тип, не примитив. Защищает от случайной арифметики. type Money struct { Amount int64 // minor units: 1050 = $10.50 Currency string // ISO 4217 } func (m Money) Add(o Money) (Money, error) { if m.Currency != o.Currency { return Money{}, fmt.Errorf("currency mismatch: %s vs %s", m.Currency, o.Currency) } return Money{Amount: m.Amount + o.Amount, Currency: m.Currency}, nil } ``` ### 3. Saga vs 2PC для распределённых транзакций Платёж затрагивает несколько систем: наш ledger + внешний PSP. **2PC (двухфазный коммит) не подходит**: PSP не участвует в нашем XA-координаторе, блокировки держат ресурсы и убивают доступность, координатор — SPOF. Используем **Saga** (последовательность локальных транзакций с компенсациями): ``` 1. ledger: создать payment (status=PENDING) + hold ─ локальный ACID 2. PSP: authorize ─ внешний вызов 3a. успех → ledger: status=AUTHORIZED ─ локальный ACID 3b. ошибка → ledger: status=FAILED + release hold (комп.) ─ компенсация ``` Saga даёт eventual consistency между нами и PSP, но **строгую** консистентность внутри ledger (каждый шаг — локальный ACID). Компенсации должны быть идемпотентны. ### 4. Transactional Outbox + CDC для exactly-once публикации Антипаттерн — «закоммитить в БД, потом отправить в Kafka»: между двумя действиями процесс может упасть → событие потеряно (или наоборот, отправили, но коммит откатился → фантомное событие). Это **dual-write problem**. Решение: пишем событие в таблицу `outbox` *в той же транзакции*, что и ledger. Отдельный процесс публикует. ```go // Один ACID-коммит: ledger + idempotency + outbox. func (s *Service) Authorize(ctx context.Context, cmd AuthorizeCmd) (*Payment, error) { tx, err := s.db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelSerializable}) if err != nil { return nil, err } defer tx.Rollback() p := newPayment(cmd) // status = PENDING if _, err = tx.ExecContext(ctx, ` INSERT INTO ledger_entries (txn_id, account_id, direction, amount, currency) VALUES ($1, $2, -1, $3, $4)`, // hold = credit на счёте источника p.TxnID, cmd.SourceAccount, cmd.Amount.Amount, cmd.Amount.Currency); err != nil { return nil, err } // Событие — в outbox, в ТОЙ ЖЕ транзакции. event, _ := json.Marshal(PaymentPendingEvent{PaymentID: p.ID, TxnID: p.TxnID}) if _, err = tx.ExecContext(ctx, ` INSERT INTO outbox (id, aggregate_id, event_type, payload, created_at) VALUES ($1, $2, 'payment.pending', $3, now())`, uuid.New(), p.ID, event); err != nil { return nil, err } if err = tx.Commit(); err != nil { return nil, err } return p, nil } ``` Релеер (CDC или poller) гарантирует **at-least-once** публикацию: ```go func (r *Relayer) pump(ctx context.Context) error { rows, err := r.db.QueryContext(ctx, ` SELECT id, event_type, payload FROM outbox WHERE published_at IS NULL ORDER BY created_at LIMIT 100 FOR UPDATE SKIP LOCKED`) // несколько релееров не конфликтуют if err != nil { return err } defer rows.Close() for rows.Next() { var id uuid.UUID var typ string var payload []byte _ = rows.Scan(&id, &typ, &payload) // Kafka key = aggregate_id → порядок по платежу. Может задублироваться // (упали между publish и UPDATE) — consumer должен быть идемпотентным. if err := r.producer.Publish(ctx, typ, id.String(), payload); err != nil { return err } if _, err := r.db.ExecContext(ctx, `UPDATE outbox SET published_at = now() WHERE id = $1`, id); err != nil { return err } } return rows.Err() } ``` Предпочтительнее CDC (logical decoding/Debezium) — он читает WAL, не нагружает БД polling-ом и не пропускает события. ### 5. Webhook от PSP и их идемпотентная обработка PSP уведомляет нас асинхронно (charge succeeded). Webhook может прийти: - **несколько раз** (PSP сам делает at-least-once), - **не по порядку** (`succeeded` раньше, чем `pending`), - **с задержкой** (минуты). Правила: - **Проверка подписи** (HMAC) — иначе кто угодно «подтвердит» платёж. - **Идемпотентность**: PSP даёт `event_id`; храним обработанные `event_id`, дубликат игнорируем. - **State machine не допускает деградации**: переход из `AUTHORIZED` в `PENDING` запрещён — поздний out-of-order webhook просто отбрасываем. ```go func (h *WebhookHandler) Handle(ctx context.Context, w PSPWebhook) error { if !h.verifySignature(w) { return ErrBadSignature // 401 } // Идемпотентность по event_id провайдера. inserted, err := h.store.MarkProcessed(ctx, w.EventID) if err != nil { return err } if !inserted { return nil // уже обработали — 200, no-op } return h.fsm.Apply(ctx, w.PaymentID, mapStatus(w.Type)) // переход через FSM } ``` ### 6. Reconciliation с провайдером Даже при идеальном коде расхождения случаются (таймауты, ручные операции в PSP, чарджбэки). **Reconciliation — обязательный контур, а не опция.** - Ежедневно скачиваем settlement-файл PSP. - Сверяем построчно: каждая транзакция PSP ↔ запись ledger по `provider_ref`. - Категории расхождений: *у нас есть, у них нет* (возможно деньги не ушли), *у них есть, у нас нет* (потеряли webhook), *разные суммы/статусы*. - Расхождения → автоматический тикет + алерт, ручной разбор. Часть автоматизируется (доводящие проводки). ### 7. State machine статусов платежа Явная FSM с разрешёнными переходами — защита от невалидных и out-of-order изменений: ``` CREATED → PENDING → AUTHORIZED → CAPTURED → SETTLED ↘ FAILED │ │ ↓ ↓ VOIDED REFUNDED / PARTIALLY_REFUNDED ↓ CHARGEBACK ``` Любой переход — проверка `allowed[from][to]`. Невалидный переход → ошибка/игнор, не молчаливая порча состояния. ### 8. Exactly-once деньги «Exactly-once» в распределённых системах в общем случае недостижимо на уровне доставки. Достигается **exactly-once *effect*** = **at-least-once delivery + идемпотентные обработчики + дедупликация**: - доставка событий — at-least-once (outbox/Kafka могут дублировать); - каждый потребитель дедуплицирует по `event_id`/`txn_id`; - запись в ledger защищена уникальным индексом (`UNIQUE(txn_id, account_id, direction)` или dedup-таблица), поэтому повторная попытка той же проводки — no-op. Итог: деньги движутся ровно один раз, даже если сообщение пришло пять раз. ## Масштабирование и узкие места - **Шардинг по account_id**: ledger разрезается по аккаунту. Проводки одного аккаунта — на одном шарде → линеаризуемость баланса локальна, без распределённых блокировок. Проблема: перевод между аккаунтами на разных шардах → нужна cross-shard saga или single-writer на пару. - **Hot accounts**: маркетплейс-аккаунт продавца / платёжный шлюз партнёра принимает тысячи проводок/с → contention на одной строке баланса. Решения: - не апдейтить строку баланса синхронно, а считать баланс как `SUM(entries)` + периодические снапшоты; - **счётчик-шардинг**: баланс разбит на N суб-балансов (`balance_shard 0..N-1`), запись идёт в случайный, чтение суммирует. Снимает row-lock contention. - **Consistency vs throughput**: `SERIALIZABLE` даёт корректность, но больше откатов под нагрузкой → ретраи. Где допустимо (запись в append-only без чтения текущего баланса) — `READ COMMITTED` + уникальные индексы как гарантия. Критичный путь с проверкой лимита — `SERIALIZABLE` или явный `SELECT ... FOR UPDATE`. - **Ledger как боттлнек**: это единая точка записи правды. Митигация: CQRS — записи в ledger, чтения (история, статусы) — из реплик/проекций; разнести OLTP (горячее) и OLAP (аналитика, reconciliation) физически. - **PSP — внешний боттлнек по latency**: capture делаем асинхронно (через очередь), синхронно — только authorize. Circuit breaker + таймауты + per-PSP rate limit, чтобы один лежачий провайдер не выел все воркеры. ## Вопросы на собеседовании **В:** Почему нельзя хранить деньги в `float64`? **О:** Двоичная плавающая точка не представляет точно десятичные дроби: `0.1 + 0.2 == 0.30000000000000004`. На миллионах операций накапливается ошибка, баланс «уезжает». Храним целые minor units (`int64` центов) либо `decimal/NUMERIC`. Арифметика — на целых. **В:** Чем outbox лучше, чем «закоммитить в БД и сразу отправить в Kafka»? **О:** «Коммит + send» — это dual-write: между двумя операциями процесс может упасть. Либо событие потеряно (упали после коммита, до send), либо фантомное (отправили, коммит откатился). Outbox делает запись события частью той же ACID-транзакции, а публикацию — отдельным надёжным шагом из закоммиченного состояния. Получаем at-least-once без потерь. **В:** Идемпотентность — где именно нужен уникальный индекс и почему не хватит «проверить-потом-вставить»? **О:** `SELECT` + `INSERT` — гонка: два параллельных ретрая оба не найдут ключ и оба вставят/спишут. Нужен атомарный `INSERT ... ON CONFLICT` на колонке с `UNIQUE`-индексом: БД сериализует конфликт, второй получает отказ/replay. Уникальный индекс — единственная настоящая гарантия, остальное — гонки. **В:** Что значит «exactly-once» для денег и достижимо ли оно? **О:** Exactly-once *delivery* в общем случае недостижимо. Достижимо exactly-once *effect*: at-least-once доставка + идемпотентные потребители + дедупликация по ключу. Деньги двигаются один раз, потому что повторная проводка с тем же `txn_id` отбивается уникальным индексом, даже если сообщение пришло несколько раз. **В:** Почему saga, а не 2PC между ledger и PSP? **О:** 2PC требует, чтобы все участники поддерживали распределённый коммит (PSP не поддерживает), держит блокировки на время фазы, имеет координатор-SPOF и плохо масштабируется. Saga — цепочка локальных ACID-транзакций с компенсациями; даёт eventual consistency между системами при строгой консистентности внутри ledger. Цена: нужно проектировать компенсации и идемпотентность каждого шага. **В:** Webhook от Stripe пришёл дважды и не по порядку (`succeeded` раньше `pending`). Что делаете? **О:** Дубликат — дедупим по `event_id` провайдера (таблица обработанных событий, `INSERT` под уникальный индекс). Out-of-order — гасим через FSM: переход `AUTHORIZED → PENDING` запрещён, поздний устаревший webhook просто отбрасывается. Плюс обязательная проверка HMAC-подписи до любой обработки. **В:** Hot account (мерчант с тысячами проводок/с) упирается в row-lock на балансе. Как масштабируете? **О:** Не апдейтить строку баланса синхронно. Баланс = `SUM` append-only проводок + периодические снапшоты; для записи — sharded counter (N суб-балансов, пишем в случайный, читаем суммой). Это убирает contention на одной строке ценой более дорогого чтения баланса (которое кэшируем/снапшотим). **В:** Зачем reconciliation, если код корректный и идемпотентный? **О:** Внешний мир недетерминирован: таймауты (мы не знаем, прошёл ли платёж), ручные операции в PSP, чарджбэки, потерянные webhook, баги. Reconciliation — независимая сверка с settlement-файлами провайдера, ловит расхождения, которые код в принципе не может предотвратить. Для денег это контроль, а не опция. **В:** Какой уровень изоляции выберете для списания с проверкой лимита баланса? **О:** Проверка «хватает ли средств» + списание — это read-modify-write, уязвимый к write skew. Нужен `SERIALIZABLE` либо явная блокировка строки (`SELECT ... FOR UPDATE`). Для чистого append без чтения баланса достаточно `READ COMMITTED` + уникальный индекс. Под нагрузкой `SERIALIZABLE` даёт откаты — обрабатываем ретраями с backoff. ## На что копают на senior+ - **Семантика «потерянного ответа»**: PSP вернул таймаут — деньги списаны или нет? Senior обязан спроектировать переход в `UNKNOWN`/`PENDING` + последующий статусный poll/reconciliation, а не «считать failed». Двойной charge рождается именно здесь. - **Точная граница идемпотентности**: уникальный индекс и `INSERT ON CONFLICT`, а не `SELECT-then-INSERT`; проверка request-hash; TTL и обработка зависшего `in_progress`; что возвращать на параллельный конфликт (`409`). - **Dual-write осознан**: кандидат сам называет проблему и тянет outbox/CDC, отличает CDC от polling, понимает `FOR UPDATE SKIP LOCKED` для нескольких релееров. - **Деньги как тип, а не int**: `Money{amount, currency}`, запрет смешения валют, округление по правилам валюты, никаких float — на уровне доменной модели. - **Append-only и компенсации**: исправление — reversal-проводкой, а не UPDATE/DELETE. Понимание, что immutable ledger = аудит. - **PCI scope minimization**: «мы не храним PAN/CVV, токенизация на PSP» — снижение области PCI DSS, а не «зашифруем карты у себя». - **CAP-выбор осознан**: для критичного пути — CP (лучше отказать, чем провести дважды); где можно — eventual consistency (история, нотификации). - **Cross-shard переводы**: понимает, что перевод между шардами — это распределённая транзакция/saga, и не делает вид, что шардинг бесплатен. - **Out-of-order и дедуп на каждом стыке**: webhook, Kafka-consumer, релеер — везде at-least-once, везде дедуп; FSM с явными разрешёнными переходами. - **Numbers sense**: оценивает TPS, размер ledger за годы, отделяет горячие данные от холодных, понимает, что PSP — главный источник latency и проектирует capture асинхронно.