Как в микросервисах работать с базами данных при разделении баз

Что проверяют

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

Как отвечать

Базовое правило: у каждого сервиса своя база, и никто не ходит в чужую напрямую. Общая база превращает набор сервисов в распределённый монолит: любое изменение схемы затрагивает всех, а независимые выкаты становятся невозможными.

Что из этого следует и как с этим живут:

• соединений между базами больше нет. Данные собираются вызовом соседнего сервиса, либо заранее реплицируются к себе в виде проекции: сервис подписывается на события и хранит нужный минимум чужих данных у себя;
• общей транзакции нет. Согласованность становится итоговой: используется схема саги с компенсирующими действиями, где каждый шаг умеет откатить свой эффект;
• надёжная отправка событий: запись в свою базу и отправка сообщения должны быть атомарны, иначе события теряются или дублируются. Для этого применяют схему исходящих сообщений (outbox), когда событие пишется в ту же транзакцию, а отправляется отдельным процессом;
• идемпотентность: доставка «хотя бы один раз» означает повторы, поэтому обработчик обязан узнавать уже обработанное событие по ключу;
• отчёты по нескольким сервисам строят не запросом, а отдельным хранилищем, куда данные стекаются событиями;
• миграции: обратная совместимость обязательна, схема меняется в два шага, чтобы старая и новая версии сервиса работали одновременно.

Где спотыкаются

Оставляют общую базу и называют это микросервисами.

Пытаются собрать распределённую транзакцию через двухфазную фиксацию и получают хрупкую и медленную систему.

Ходят в чужую базу «только на чтение», после чего чужая схема становится публичным контрактом, который нельзя менять.