🟢 Junior Level

Database per Service — каждый микросервис имеет свою собственную базу данных, которую никто другой не использует напрямую.

Цена: вы больше не можете сделать SELECT … JOIN между таблицами разных сервисов. Вместо этого — API-вызовы или событийная репликация.

Order Service → Order DB
User Service → User DB
Payment Service → Payment DB

Зачем:

• Независимость — каждый сервис может менять свою схему без других
• Изоляция — падение БД одного сервиса не влияет на другие
• Гибкость — разные сервисы могут использовать разные БД (SQL, NoSQL)

---

🟡 Middle Level

Когда НЕ использовать Database per Service

• Маленькая команда (2-3 dev) — не справятся с управлением нескольких БД
• Стартап в фазе валидации — схема меняется ежедневно
• Строгая консистентность для отчётности — сложно с eventual consistency

Как сервисы получают данные друг друга

1. API calls:

Order Service → User Service API → получить данные пользователя

2. Event-driven:

User Service → "UserUpdated" event → Order Service слушает и кэширует

3. CQRS:

(CQRS — Command Query Responsibility Segregation, разделение моделей для записи и чтения.)
(Materialized View — предварительно вычисленное представление данных для быстрых запросов.)
Write model → Order DB
Read model → Materialized view (из events)

Типичные ошибки

1. Shared database:

   Order Service → User table напрямую
   Нарушение инкапсуляции → coupling
   

---

🔴 Senior Level

Архитектурные Trade-offs

Database per Service	Shared Database
Полная изоляция	Проще
Eventual consistency: когда User Service обновил данные и опубликовал event, Order Service получит его с задержкой (мс или секунды). В этот промежуток Order Service видит старую версию данных.	ACID транзакции
Сложные запросы между сервисами	Кросс-сервисные JOIN
Независимый деплой	Координированный деплой

Production Experience

Polyglot persistence:

(Polyglot Persistence — использование разных СУБД для разных задач.)
User Service → PostgreSQL
Session Service → Redis
Analytics Service → ClickHouse
Search Service → Elasticsearch

Database per Service vs Schema per Service

Можно иметь логическую изоляцию (отдельные схемы) на одном физическом сервере БД. Это компромисс: проще в эксплуатации, но меньше изоляции при падении сервера.

Best Practices

✅ Каждый сервис — своя БД
✅ API или events для доступа к данным
✅ Polyglot persistence когда нужно
✅ Eventual consistency

❌ Прямой доступ к БД другого сервиса
❌ Shared database между сервисами
❌ Distributed transactions без необходимости

---

🎯 Шпаргалка для интервью

Обязательно знать:

• Database per Service — каждый микросервис имеет СВОЮ БД, никто другой не использует напрямую
• Независимость: каждый сервис меняет схему без других, изоляция при падении
• Сервисы получают данные друг друга через API calls, events, или CQRS
• Polyglot persistence — разные сервисы могут использовать разные СУБД
• Eventual consistency: данные другого сервиса могут быть устаревшими на мс-секунды
• Можно логическую изоляцию (separate schemas) на одном физическом сервере — компромисс
• НЕ подходит для маленьких команд (2-3 dev) и стартапов с частой сменой схемы

Частые уточняющие вопросы:

• Как получить данные другого сервиса? API call (синхронно), event-driven (асинхронно), или materialized view (CQRS).
• Что такое polyglot persistence? User Service → PostgreSQL, Session → Redis, Analytics → ClickHouse.
• Database per Service vs Schema per Service? Schema per Service — логическая изоляция на одном сервере — проще в эксплуатации, но меньше изоляции при падении.
• Когда НЕ использовать? Маленькая команда, стартап, строгая консистентность для отчётности.

Красные флаги (НЕ говорить):

• “Можно читать из БД другого сервиса напрямую” — нарушение инкапсуляции, coupling
• “Eventual consistency = данные всегда неверны” — нет, станут верными через время
• “JOIN между сервисами — нормальная практика” — нет, это anti-pattern
• “Каждому сервису нужен отдельный сервер БД” — нет, можно schemas на одном сервере

Связанные темы:

• [[1. Что такое паттерн Saga и когда его использовать]]
• [[3. Как реализовать распределённые транзакции в микросервисах]]
• [[14. Какие проблемы возникают при использовании общей базы данных]]
• [[15. Как организовать коммуникацию между микросервисами]]
• [[16. В чём разница между синхронной и асинхронной коммуникацией]]