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 - Стандарт SQL определяет 4 уровня изоляции: **Read Uncommitted**, **Read Committed**, **Repeatable Read**, **Serializable** — и описывает их через 3 запрещённые аномалии (dirty read, non-repeatable read, phantom read). - Стандарт определяет уровни через аномалии, а не через механизм. PostgreSQL реализует их через **MVCC (snapshot isolation)**, поэтому реальная защита от аномалий *строже*, чем минимально требует стандарт. - В PostgreSQL фактически **три** уровня: `READ UNCOMMITTED` ведёт себя как `READ COMMITTED` (грязного чтения не существует никогда — MVCC отдаёт только закоммиченные версии строк). - **Read Committed** (дефолт) — снимок берётся на каждый отдельный statement. Защищает от dirty read, но допускает non-repeatable read, phantom read и lost update между statements. - **Repeatable Read** в PG — это полноценный **snapshot isolation**: один снимок на всю транзакцию. Предотвращает dirty/non-repeatable/phantom read (в отличие от стандарта, где RR допускает phantom). Но допускает **write skew** и при конфликте на запись бросает `40001`. - **Serializable** в PG реализован через **SSI (Serializable Snapshot Isolation)**: отслеживает зависимости чтения/записи через predicate locks (SIReadLock) и откатывает транзакции с `serialization_failure` (SQLSTATE `40001`), нарушающие сериализуемость, включая write skew. - На уровнях RR и Serializable код **обязан** иметь retry-цикл на `40001` (и `40P01` deadlock). Без него приложение будет случайно падать под нагрузкой. ## Теория ### Стандарт SQL: уровни через аномалии Стандарт ANSI/ISO SQL не описывает *как* СУБД должна изолировать транзакции, а только *какие аномалии запрещены* на каждом уровне. Аномалии: - **Dirty read** — транзакция читает данные, записанные другой ещё не закоммиченной транзакцией. Если та откатится — мы прочитали то, чего «не было». - **Non-repeatable read** — транзакция дважды читает одну и ту же строку и получает разные значения, потому что между чтениями другая транзакция закоммитила `UPDATE`/`DELETE` этой строки. - **Phantom read** — транзакция дважды выполняет один и тот же запрос по диапазону (предикату), и во второй раз появляются новые строки (`INSERT` другой транзакции), удовлетворяющие предикату. Классическая таблица стандарта: | Уровень | Dirty read | Non-repeatable read | Phantom read | |------------------|--------------|---------------------|--------------| | Read Uncommitted | возможен | возможен | возможен | | Read Committed | нет | возможен | возможен | | Repeatable Read | нет | нет | возможен | | Serializable | нет | нет | нет | Важно: эта таблица — *минимальные* требования. СУБД вправе быть строже. Также в стандарте есть «дыра»: он определён через локинг-ориентированную модель и не покрывает аномалии snapshot isolation, такие как **write skew** (описана в статье Berenson et al. «A Critique of ANSI SQL Isolation Levels», 1995). PostgreSQL использует MVCC, а не двухфазный локинг, поэтому привязка к этой таблице неполна. ### Аномалии, которых нет в стандартной таблице - **Lost update** — две транзакции читают одно значение, обе вычисляют новое на его основе и записывают; одна перезаписывает другую, обновление теряется. Пример: `balance = balance + 100` через read-modify-write в коде приложения. - **Write skew** — две транзакции читают *пересекающийся* набор данных, принимают решение на основе прочитанного и пишут в *разные* строки. Каждая по отдельности корректна, но вместе нарушают инвариант. Snapshot isolation (PG Repeatable Read) её **не ловит**. - **Read-only transaction anomaly** — даже транзакция, которая только читает, может увидеть несериализуемое состояние при snapshot isolation. SSI это учитывает. ### Что РЕАЛЬНО реализовано в PostgreSQL PostgreSQL построен на **MVCC**: каждая строка имеет версии (`xmin`/`xmax`), и транзакция видит снимок (snapshot) — набор версий, закоммиченных на определённый момент. Из этого следуют ключевые отличия от стандарта: #### Read Uncommitted == Read Committed В PG грязное чтение **невозможно физически**: снимок никогда не включает незакоммиченные версии чужих транзакций. Запрос `SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED` принимается, но движок трактует его как `READ COMMITTED`. Это легально по стандарту (СУБД может быть строже). #### Read Committed (дефолт) - Снимок берётся **в начале каждого SQL-statement**, а не транзакции. - Каждая новая команда видит данные, закоммиченные до её старта. Поэтому два `SELECT` в одной транзакции могут вернуть разное — non-repeatable и phantom read возможны. - Особенность для пишущих команд: если `UPDATE`/`DELETE`/`SELECT FOR UPDATE` натыкается на строку, заблокированную другой транзакцией, он **ждёт**; после её коммита перечитывает строку (re-evaluates) уже с новой версией и применяет условие `WHERE` заново. Это так называемый «EvalPlanQual» — источник тонких багов. #### Repeatable Read == Snapshot Isolation - Снимок берётся **один раз** на первую команду транзакции (точнее, на первый запрос, читающий/пишущий данные) и используется до конца. - Предотвращает dirty read, non-repeatable read **и phantom read** — то есть строже стандарта (стандарт допускает phantom на RR). - НЕ предотвращает **write skew** и read-only anomaly. - При попытке обновить строку, изменённую и закоммиченную другой транзакцией после начала снимка, бросает: `ERROR: could not serialize access due to concurrent update` — SQLSTATE `40001`. Транзакцию нужно повторить. #### Serializable == SSI (Serializable Snapshot Isolation) PostgreSQL (с 9.1) реализует настоящую сериализуемость поверх snapshot isolation через алгоритм **SSI** (Cahill et al.): - Поверх обычного snapshot isolation движок отслеживает зависимости между транзакциями через **predicate locks** (видны как `SIReadLock` в `pg_locks`). Они не блокируют — это «отметки» о том, какие диапазоны/строки транзакция прочитала. - SSI ищет паттерн «опасной структуры» — два последовательных rw-конфликта (rw-antidependency), образующих цикл, который делает расписание несериализуемым. - Если обнаружен потенциально несериализуемый порядок, одна из транзакций откатывается с: `ERROR: could not serialize access due to read/write dependencies among transactions` — SQLSTATE `40001`. - Гарантирует, что любой успешно закоммиченный набор транзакций эквивалентен какому-то *последовательному* их выполнению. Это ловит и write skew, и read-only anomaly. Важно: predicate locks потребляют память (`max_pred_locks_per_transaction`), могут эскалировать с уровня строки до страницы/отношения, что увеличивает число ложных конфликтов и `40001`. ### Сводная таблица: стандарт vs PostgreSQL | Аномалия | RU std | RU PG | RC std | RC PG | RR std | RR PG | S std | S PG | |-----------------------|--------|-------|--------|-------|--------|-------|-------|------| | Dirty read | да | нет | нет | нет | нет | нет | нет | нет | | Non-repeatable read | да | да | да | да | нет | нет | нет | нет | | Phantom read | да | да | да | да | да | нет | нет | нет | | Lost update | да | да | да | да | нет* | нет* | нет | нет | | Write skew | да | да | да | да | да | да | нет | нет | \* На RR lost update «теряется» в виде тихой перезаписи нет — вместо этого PG бросает `40001` при конфликте записи (first-updater-wins с откатом второго). На RC lost update в чистом read-modify-write через приложение возможен. ### SET TRANSACTION ISOLATION LEVEL ```sql -- Установка уровня для текущей транзакции (только сразу после BEGIN, до первого запроса) BEGIN; SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- ... запросы ... COMMIT; -- Компактная форма BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; -- Read-only транзакция (на SERIALIZABLE даёт оптимизацию SSI + DEFERRABLE) BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE READ ONLY DEFERRABLE; -- Дефолт уровня для всех новых транзакций сессии SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL REPEATABLE READ; -- Глобально (postgresql.conf / ALTER SYSTEM / ALTER DATABASE) -- default_transaction_isolation = 'read committed' ``` `READ ONLY DEFERRABLE` на Serializable: транзакция дождётся «безопасного» снимка и тогда никогда не получит `40001` и никого не заставит откатиться — полезно для длинных аналитических read-only запросов. ### Пример write skew Инвариант: «хотя бы один врач должен быть on-call». Два врача одновременно снимают себя с дежурства. ```sql -- Таблица CREATE TABLE doctors (id int PRIMARY KEY, name text, on_call boolean); INSERT INTO doctors VALUES (1, 'Alice', true), (2, 'Bob', true); -- Транзакция A (Alice) -- Транзакция B (Bob) BEGIN ISOLATION LEVEL REPEATABLE READ; BEGIN ISOLATION LEVEL REPEATABLE READ; -- A видит: on_call = 2 SELECT count(*) FROM doctors WHERE on_call; -- 2 -- B видит свой снимок: on_call = 2 SELECT count(*) FROM doctors WHERE on_call; -- 2 -- 2 >= 1, можно снять Alice UPDATE doctors SET on_call=false WHERE id=1; -- 2 >= 1, можно снять Bob (по СВОЕМУ снимку) UPDATE doctors SET on_call=false WHERE id=2; COMMIT; COMMIT; -- Итог: НИ ОДНОГО on-call врача. Инвариант нарушен. ``` На **REPEATABLE READ** обе транзакции коммитятся успешно — пишут в разные строки, конфликта записи нет. Write skew проходит. На **SERIALIZABLE** SSI замечает rw-зависимость (обе читали один диапазон `WHERE on_call`, и обе его изменили), и одна из транзакций при `COMMIT` (или раньше) получит: ``` ERROR: could not serialize access due to read/write dependencies among transactions DETAIL: Reason code: Canceled on identification as a pivot ... HINT: The transaction might succeed if retried. ``` Альтернатива без Serializable — явно материализовать конфликт через блокировку читаемых строк: ```sql -- На RC/RR это закрывает write skew: SELECT FOR UPDATE блокирует прочитанные строки, -- вторая транзакция ждёт и перечитывает актуальное состояние. SELECT count(*) FROM doctors WHERE on_call FOR UPDATE; ``` Но `FOR UPDATE` не блокирует *фантомные* INSERT'ы (нет строки — нечего блокировать), поэтому от write skew с появлением новых строк спасает только Serializable или явные advisory/предметные блокировки. ### Lost update: демонстрация ```sql -- READ COMMITTED, read-modify-write в приложении (АНТИПАТТЕРН) -- A: SELECT balance FROM accounts WHERE id=1; -- 100 -- B: SELECT balance FROM accounts WHERE id=1; -- 100 -- A: UPDATE accounts SET balance=200 WHERE id=1; (100+100) -- B: UPDATE accounts SET balance=200 WHERE id=1; (100+100) -- потеряли +100 от A -- ПРАВИЛЬНО: атомарно в БД UPDATE accounts SET balance = balance + 100 WHERE id = 1; -- Либо оптимистично через версию UPDATE accounts SET balance = $1, version = version + 1 WHERE id = 1 AND version = $2; -- если 0 строк затронуто — кто-то опередил, retry ``` На RR второй `UPDATE balance=balance+100` той же строки после коммита первого даст `40001`, а не тихую потерю. ### Обработка serialization_failure (40001) с retry в Go Ключевой паттерн: на RR/Serializable любая транзакция может легально упасть с `40001`, и это **не ошибка приложения**, а сигнал «повтори». Нужен идемпотентный retry с backoff. `database/sql` + `lib/pq`: ```go import ( "context" "database/sql" "errors" "math/rand" "time" "github.com/lib/pq" ) // isRetryable: 40001 (serialization_failure) и 40P01 (deadlock_detected) func isRetryable(err error) bool { var pqErr *pq.Error if errors.As(err, &pqErr) { switch pqErr.Code { case "40001", "40P01": return true } } return false } func withRetry(ctx context.Context, db *sql.DB, fn func(*sql.Tx) error) error { const maxAttempts = 5 var lastErr error for attempt := 0; attempt < maxAttempts; attempt++ { tx, err := db.BeginTx(ctx, &sql.TxOptions{ Isolation: sql.LevelSerializable, // или LevelRepeatableRead }) if err != nil { return err } if err = fn(tx); err != nil { _ = tx.Rollback() if isRetryable(err) { lastErr = err // экспоненциальный backoff с джиттером backoff := time.Duration(1<