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

Можно ли иметь единую БД для всех микросервисов?

Технически — да, возможно. Вы можете развернуть один экземпляр базы данных (например, PostgreSQL, MySQL) и предоставить доступ к ней всем микросервисам в системе. Однако с архитектурной точки зрения это считается антипаттерном в мире микросервисов и нарушает ключевые принципы, ради которых эта архитектура создавалась.

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

Почему это антипаттерн? Ключевые проблемы

1. Нарушение принципа слабой связанности (Loose Coupling)

    *   Микросервисы становятся **сильно связанными (tightly coupled)** через общую схему данных. Изменение таблицы, необходимой одному сервису, может случайно сломать работу другого.
    *   Исчезает **независимость развертывания (independent deployability)** — чтобы обновить один сервис, нужно координировать изменения БД со всеми командами, которые её используют.

1. Потеря контекстной границы (Bounded Context)

    *   Единая БД смешивает данные и бизнес-логику разных доменов. Модель `Заказ` из сервиса заказов и модель `Товар` из сервиса каталога оказываются в одном пространстве, что ведет к сложностям и неоднозначностям.
    *   Это прямая дорога к **"большому шару грязи" (Big Ball of Mud)** на уровне данных.

1. Проблемы с масштабированием и производительностью

    *   База данных становится **единой точкой отказа (SPOF)**. Сбой БД парализует всю систему.
    *   Все сервисы конкурируют за ресурсы одного инстанса (CPU, I/O, соединения). Пиковая нагрузка на один сервис может "уронить" БД для всех остальных.
    *   Горизонтальное масштабирование становится крайне сложным, так как нельзя шардировать или реплицировать данные изолированно под конкретный сервис.

1. Трудности с безопасностью и правами доступа

    *   Сложно изолировать права. Сервис для уведомлений теоретически получает доступ к финансовым транзакциям или персональным данным пользователей, увеличивая поверхность атаки.

1. Нарушение принципа владения данными (Database per Service)

    *   Каноничный подход микросервисов гласит: **"сервис владеет своими данными"**. Только он имеет прямой доступ к своей БД. Вся коммуникация с другими сервисами идет через четко определенные API (чаще всего REST, gRPC или асинхронные сообщения).

Как должна выглядеть правильная архитектура?

Каждый микросервис управляет своей собственной базой данных. Это может быть отдельный физический инстанс, отдельная схема (schema) в общем кластере или даже база другого типа (полиглотная персистентность).

# Пример описания сервисов в docker-compose (упрощенно)
version: '3.8'
services:
  order-service:
    build: ./order
    environment:
      - DB_HOST=orders_db # Своя БД
    depends_on:
      - orders_db

  catalog-service:
    build: ./catalog
    environment:
      - DB_HOST=catalog_db # Своя БД
    depends_on:
      - catalog_db

  orders_db:
    image: postgres:15
    environment:
      POSTGRES_DB: orders

  catalog_db:
    image: postgres:15 # Или даже MongoDB, если нужно
    environment:
      POSTGRES_DB: catalog

Для обмена данными между сервисами используются два основных паттерна:

• API-композиция (API Composition): Сервис-агрегатор (или API Gateway) запрашивает данные у нескольких сервисов через их API и объединяет ответ.
• Саги (Sagas): Для распределенных транзакций используется последовательность событий или команд, чтобы обеспечить согласованность данных в конечном счете (Eventual Consistency).

Исключения и компромиссы

В реальности абсолютная изоляция — это идеал. Иногда идут на осознанные компромиссы:

1. Этап запуска (Startup) или очень простые системы. Одна БД резко снижает операционную сложность. Но важно сразу заложить в код изоляцию (отдельные схемы) и быть готовым к расщеплению (strangler fig pattern), когда система вырастет.
2. Монорепозиторий с общими "справочными" данными. Например, таблица стран или валют, которая редко меняется и нужна многим сервисам. Но даже здесь лучше:

    *   Выделить отдельный `reference-service`, владеющий этими данными.
    *   Реплицировать/кэшировать данные в другие сервисы через события (`CDC` - Change Data Capture).

```sql
-- Плохо: все сервисы лезут в одну таблицу
SELECT * FROM public.countries;

-- Лучше: каждый сервис работает в своей схеме, а общие данные синхронизируются
-- Сервис A
SELECT * FROM service_a_schema.countries_cache;
-- Сервис B
SELECT * FROM service_b_schema.countries_cache;
```

3. Операционная аналитика и отчетность. Для сложных кросс-доменных отчетов данные изолированных БД сливают в единое хранилище данных (Data Warehouse) или озеро данных (Data Lake) через ETL/ELT-процессы, но не для операционной работы.

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