🟢 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. У чому різниця між синхронною та асинхронною комунікацією]]