intermediate

Data Modeling & Transactions

Schema design and transaction behavior — normalization and denormalization, constraints, surrogate keys, store choice, isolation, locking, and database scaling.

go-data-modeling

Practice: 13 questions →

Sections

Contents

Detailed explanation

Data Modeling & Transactions

Go code is rarely complex on its own — a goroutine takes a request, hits PostgreSQL, returns a response. The real complexity sits in two places: how the schema is designed and how transactions behave once writers pile up. database/sql and pgx give you direct SQL access but protect you from no conceptual mistake — wrong table decomposition, wrong surrogate key, wrong isolation level, wrong lock ordering: all of it compiles, passes local tests, and surfaces only under concurrent load.

The traps here are not about syntax. Candidates confuse normalization with compression and think higher normal forms merge tables rather than splitting them. They denormalize prematurely and forget the cost is paid on every write. They take a random UUID as "just another key", not noticing it breaks B-tree append locality. They believe SELECT FOR UPDATE is a shared read lock and expect the application to detect deadlocks itself. They think Read Committed saves them from phantoms and that a read replica scales writes. This topic dissects design and transactions layer by layer — so you answer each of these questions with a mechanism, not a memorized phrase.

Topic Map

Normalization — 1NF/2NF/3NF, storing every fact exactly once, and eliminating update, insert, and delete anomalies.
Denormalization — deliberate redundancy to cut joins off the read path, and the cost paid on every write.
Constraints — NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK as race-safe invariants inside the database itself.
Surrogate Keys — serial vs UUID — a compact serial with B-tree append locality versus a globally unique but scattered UUID.
Document vs Relational Databases — flexible schema and embedding versus joins, multi-row ACID, and referential integrity.
OLAP vs OLTP — a row-store transactional engine versus a column-store analytical one, and why the physical on-disk layout decides everything.
Transaction Isolation — three anomalies, four levels, PostgreSQL's stronger Repeatable Read, and durability via the WAL.
Row Locking — SELECT FOR UPDATE, lock acquisition order, and why two transactions deadlock.
Optimistic Locking — a version column instead of holding a lock, conflict detection via rows affected, and retry.
Database Scaling — vertical, cache, read replica, connection pool, and sharding, with their trade-offs across reads, writes, and complexity.

Common Mistakes and Traps

Mistake	Consequence
Confusing normalization with compression or query speedup	A wrong mental model — it is schema-design discipline for correctness, not storage
Thinking higher normal forms merge tables	The opposite — they split data into more tables, removing duplicates
Denormalizing prematurely, without a read profile	Harder writes and a desync risk with no proven benefit
Relying on validation in the service code alone	Manual SQL, other services, and races bypass it — only a `UNIQUE` in the database is race-safe
Treating `PRIMARY KEY` as just `UNIQUE`	It is also `NOT NULL` and defines row identity that `FOREIGN KEY`s reference
Saying "`UUID` is slower than `serial`" without the cause	The cause is lost `B-tree` append locality from random inserts and page splits, not "big bytes"
Calling a document database "schemaless"	A schema exists, flexible on write; embedding removes joins, it does not add them
Thinking `OLAP` is "`OLTP` but bigger"	The difference is layout — rows versus columns — under the query profile, not size
Treating `Serializable` as the weakest isolation level	An inverted model — `Serializable` is the strongest, `Read Uncommitted` the weakest
Thinking `Read Committed` catches phantom reads	Both non-repeatable and phantom reads remain possible on it
Treating `SELECT FOR UPDATE` as a shared read lock	It is an exclusive row write lock — concurrent writers wait
Expecting the application itself to detect deadlocks	The DBMS detects and breaks the lock cycle; the code only retries the victim transaction
Treating optimistic locking as a "lock" in the database	There is no lock at all — the defense rests on a `version` column and the rows-affected check
Treating a `read replica` as a way to scale writes	Replicas offload reads only; writes still bottleneck on the single primary

Interview Relevance

Data design and transactions are a mandatory topic on any backend interview, and the question is not "do you know the word normalization" but whether you can reason about correctness, cost, and concurrency.

What interviewers check:

Why you normalize a schema — eliminating redundancy and anomalies, not query speed; and why higher forms split tables.
When you deliberately denormalize and what you pay for it on the write side.
Why an invariant goes in the database (UNIQUE, FOREIGN KEY, CHECK), not only in the service code.
The difference between serial and UUID at the B-tree level, and why UUIDv7 exists.
How a document database differs from a relational one and which guarantees you lose.
How a column-store OLAP engine differs from a row-store OLTP one and why it is about on-disk layout.
The four isolation levels, three anomalies, which level forbids what — and PostgreSQL's specifics.
What SELECT FOR UPDATE does, why the opposite acquisition order deadlocks, and when you take optimistic locking instead.
Which mechanisms scale reads versus writes, and the cost of each.

A typical wrong answer: "Read Committed is the safe level, it protects against all read anomalies". That triggers a discussion of how Read Committed forbids only dirty reads, while non-repeatable and phantom reads remain possible on it, and how the choice of level is a deliberate trade-off between correctness and concurrency.

Why it matters

A Go service lives exactly as well as its schema and its transaction behavior under concurrent load are thought through. Fail to tell normalization from compression, think `Read Committed` catches phantoms, take `SELECT FOR UPDATE` for a shared read lock, or treat a surrogate `UUID` as "just a key" — and you write code that passes tests and falls apart in production once the writers pile up.

Моделирование данных и транзакции

Проектирование схемы и поведение транзакций — нормализация и денормализация, ограничения целостности, суррогатные ключи, выбор хранилища, изоляция, блокировки и масштабирование базы.

IT Abyss

Моделирование данных и транзакции

Код на Go редко бывает сложным сам по себе — горутина приняла запрос, сходила в PostgreSQL, отдала ответ. Настоящая сложность сосредоточена в двух местах: как спроектирована схема и как ведут себя транзакции, когда писателей становится много. database/sql и pgx дают прямой доступ к SQL, но не защищают ни от одной концептуальной ошибки — неверная декомпозиция таблиц, неверный суррогатный ключ, неверный уровень изоляции, неверный порядок блокировок: всё это компилируется, проходит локальные тесты и проявляется только под параллельной нагрузкой.

Ловушки тут не про синтаксис. Кандидаты путают нормализацию со сжатием и думают, что высшие нормальные формы объединяют таблицы, а не дробят их. Денормализуют преждевременно и забывают, что цену платит каждая запись. Берут случайный UUID за «просто другой ключ», не замечая, что он ломает append-локальность B-tree. Считают SELECT FOR UPDATE разделяемой блокировкой чтения и ждут, что приложение само должно ловить deadlock. Думают, что Read Committed спасает от фантомов, а read replica масштабирует запись. Эта тема разбирает проектирование и транзакции по слоям — так, чтобы каждый из этих вопросов вы закрывали механизмом, а не заученной фразой.

Карта темы

Нормализация — 1NF/2NF/3NF, хранение каждого факта ровно один раз и устранение аномалий обновления, вставки и удаления.
Денормализация — намеренная избыточность ради сокращения join на пути чтения и её цена при каждой записи.
Ограничения целостности — NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK как гонко-устойчивые инварианты в самой базе.
Суррогатные ключи — serial и UUID — компактный serial с append-локальностью в B-tree против глобально уникального, но разбросанного UUID.
Документные vs реляционные базы — гибкая схема и встраивание против join, многострочного ACID и ссылочной целостности.
OLAP против OLTP — строковое транзакционное хранилище против колоночного аналитического и почему всё решает физическая раскладка на диске.
Изоляция транзакций — три аномалии, четыре уровня, особенность Repeatable Read в PostgreSQL и устойчивость через WAL.
Блокировка строк — SELECT FOR UPDATE, порядок захвата блокировок и почему две транзакции сходятся во взаимоблокировке.
Оптимистичная блокировка — колонка version вместо удержания лока, конфликт по числу затронутых строк и повтор.
Масштабирование БД — вертикаль, кеш, read replica, пул соединений и sharding с их компромиссами по чтению, записи и сложности.

Частые ошибки и ловушки

Ошибка	Последствие
Путать нормализацию со сжатием или ускорением запросов	Неверная ментальная модель — это дисциплина проектирования схемы ради корректности, не storage
Думать, что высшие нормальные формы объединяют таблицы	Наоборот — они дробят данные на больше таблиц, убирая дубликаты
Денормализовать преждевременно, без профиля чтений	Усложнённая запись и риск рассинхрона без доказанной выгоды
Полагаться на валидацию только в коде сервиса	Инвариант обходят ручной SQL, другие сервисы и гонки — `UNIQUE` в базе единственно гонко-устойчив
Считать `PRIMARY KEY` просто `UNIQUE`	Он ещё `NOT NULL` и задаёт идентичность строки, на которую ссылаются `FOREIGN KEY`
Сказать «`UUID` медленнее `serial`», не назвав причину	Причина — потеря append-локальности `B-tree` из-за случайных вставок и расщеплений страниц, а не «большие байты»
Считать документную базу «базой без схемы»	Схема есть, она гибкая на запись; встраивание убирает join, а не добавляет
Думать, что `OLAP` — это «`OLTP`, но больше»	Разница не в размере, а в раскладке: строки против колонок под профиль запроса
Считать `Serializable` слабейшим уровнем изоляции	Перевёрнутая модель — `Serializable` сильнейший, `Read Uncommitted` слабейший
Думать, что `Read Committed` ловит фантомные чтения	На нём возможны и неповторяющиеся, и фантомные чтения
Считать `SELECT FOR UPDATE` разделяемой блокировкой чтения	Это эксклюзивная блокировка строки на запись — конкурентные писатели ждут
Ждать, что приложение само должно ловить deadlock	Цикл блокировок обнаруживает и рвёт сама СУБД; код лишь повторяет транзакцию-жертву
Считать оптимистичную блокировку «локом» в базе	Лока нет вовсе — защита держится на колонке `version` и проверке числа затронутых строк
Считать `read replica` способом масштабировать запись	Реплики снимают только чтения; запись по-прежнему упирается в единственный primary

Значение для собеседований

Проектирование данных и транзакции — обязательная тема на любом backend-интервью, и спрашивают не «знаешь ли ты слово нормализация», а умеешь ли ты рассуждать о корректности, цене и конкурентности.

Что обычно проверяют:

Зачем нормализуют схему — устранение избыточности и аномалий, а не скорость запросов; и почему высшие формы дробят таблицы.
Когда осознанно денормализуют и чем за это платят на стороне записи.
Почему инвариант ставят в базе (UNIQUE, FOREIGN KEY, CHECK), а не только в коде сервиса.
В чём разница serial и UUID на уровне B-tree и зачем нужен UUIDv7.
Чем документная база отличается от реляционной и какие гарантии вы теряете.
Чем колоночное OLAP-хранилище отличается от строкового OLTP и почему это про раскладку на диске.
Четыре уровня изоляции, три аномалии и какой уровень что запрещает — и особенность PostgreSQL.
Что делает SELECT FOR UPDATE, почему противоположный порядок захвата даёт deadlock и когда вместо лока берут оптимистичную блокировку.
Какими механизмами масштабируют чтения и записи и какова цена каждого.

Типичный неверный ответ: «Read Committed — это безопасный уровень, он защищает от всех аномалий чтения». Это запускает разбор того, что Read Committed запрещает только грязное чтение, а неповторяющиеся и фантомные чтения на нём по-прежнему возможны, и что выбор уровня — это сознательный компромисс между корректностью и конкурентностью.