Микросервисы и данные: кто владелец, если сервисов много

В последние год-два тема микросервисов вышла из узких технических кругов и добралась до совещаний уровня директора. Разбивать большие системы на небольшие, независимо развёртываемые части - звучит правильно. Но в разговорах о выгодах почти никогда не упоминается то, что становится главной проблемой на практике: данные.

Когда монолит разбивают на сервисы, возникает вопрос, на который у большинства команд нет готового ответа. Если заказ создаётся в одном сервисе, клиент живёт в другом, а склад - в третьем, то кто из них отвечает за то, чтобы данные были согласованы?

Откуда берётся проблема

В монолите всё лежит в одной базе данных. Транзакция - атомарная. Если что-то пошло не так, откат полный. Это удобно и привычно.

В мире микросервисов у каждого сервиса своя база - иначе какая же независимость. Но это означает, что единой транзакции через несколько сервисов больше нет. Если один сервис записал данные, а следующий упал - система оказывается в промежуточном состоянии. Кто и как это разрешает?

Это не гипотетическая ситуация. Это первое, с чем сталкиваются команды через несколько месяцев после начала разбивки.

Что значит "владелец данных" в этом контексте

Владелец данных - сервис, который является единственным источником правды для этих данных. Только он пишет, только он интерпретирует, что данные означают. Все остальные либо запрашивают у него, либо получают копию через событие.

Это кажется простым, пока не начинается реальная работа. Тогда выясняется:

• несколько команд считают, что именно они должны владеть клиентским профилем;
• одни и те же поля называются по-разному в разных сервисах;
• некоторые данные никто не хочет брать себе - и они зависают между командами;
• иногда "источника правды" для конкретного факта не существует вовсе.

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

Три вопроса, которые стоит задать до начала разбивки

Я обычно спрашиваю команды, которые только заходят в микросервисную архитектуру, о трёх вещах.

Первое. Для каждой ключевой сущности - клиент, заказ, продукт, платёж - определена ли команда и сервис, которые за неё отвечают? Не "у нас есть доступ", а именно "мы отвечаем за полноту и корректность".

Второе. Как другие сервисы получают данные от владельца? Синхронный запрос (API) или асинхронное событие? Оба варианта работают, но они дают разные гарантии и требуют разного дизайна.

Третье. Что происходит при рассогласовании? Если данные в двух сервисах расходятся - это баг, допустимая задержка или ожидаемое поведение? У команды должен быть ответ, а не удивление.

Что это меняет для руководителя

Для директора или собственника всё это выглядит как детали реализации. Но последствия появляются на уровне продукта и операций.

Когда границы владения данными не определены, команды начинают дублировать логику в своих сервисах. Одна и та же проверка - в трёх местах, каждая немного отличается. Через год никто не знает, какая версия правильная.

Отчёты перестают сходиться - потому что разные сервисы дали немного разные данные в разное время. Ответ на вопрос "сколько активных клиентов" зависит от того, у кого спрашивать.

Интеграция новых систем замедляется - потому что каждый новый потребитель данных должен разобраться, у какого сервиса брать информацию и в каком виде она придёт.

Практический ориентир

Если в компании идёт или планируется разбивка на микросервисы, я рекомендую до начала работы составить простую таблицу: сущность - владелец - способ доступа. Три колонки. Пусть она будет неполной - её заполнение уже поднимет нужные разговоры.

Вопрос не в том, использовать микросервисы или нет. Вопрос в том, переносить ли туда существующий беспорядок с данными или сначала разобраться с ответственностью. Второй путь длиннее в начале и значительно короче через год.