Должна ли у каждого микросервиса быть своя база данных?

Микросервисная архитектура строится вокруг идеи слабой связанности (loose coupling) и независимого развёртывания. Если несколько сервисов пишут в одну и ту же схему БД, они становятся связанными через неё: изменение таблицы в одном сервисе ломает другой, миграции приходится синхронизировать, а масштабирование БД становится общим узким местом. Поэтому канонический принцип — database per service: каждый сервис владеет своей схемой и обращается к ней только сам.

Почему это важно

• Независимые миграции: сервис меняет схему, не затрагивая соседей.
• Свобода выбора СУБД: для поиска — Elasticsearch, для кэша — Redis, для транзакций — PostgreSQL.
• Изоляция отказов: падение одной БД не роняет весь кластер.
• Чёткие границы владения данными (bounded context из DDD).

Как сервисы обмениваются данными

Если данные нужны другому сервису, их получают через API или через события. Второй вариант предпочтительнее: сервис публикует событие в брокер (Kafka, RabbitMQ), а подписчики обновляют свои локальные проекции. Так возникает eventual consistency — данные согласованы не мгновенно, а через некоторое время.

// Сервис заказов публикует событие
await kafka.send('order.created', {
  orderId: 42,
  userId: 7,
  total: 199.99
});

// Сервис аналитики слушает и пишет в свою БД
kafka.on('order.created', async (e) => {
  await analyticsDb.insert('orders', e);
});

Компромиссы на практике

На старте проекта часто держат одну БД для нескольких сервисов — это быстрее в разработке. Но важно разделять схемы (schema per service) и запрещать прямые запросы в чужие таблицы. По мере роста сервисы выносят на отдельные инстансы. Также допустимы read-реплики и общие справочники (например, список стран), которые редко меняются.

Итог: своя БД у каждого сервиса — это цель, к которой стоит стремиться, потому что она даёт настоящую независимость. Но применять принцип нужно прагматично: на ранних этапах допустимы компромиссы, если границы владения данными соблюдаются.