🟢 Junior Level

Спільна БД — це антипатерн у мікросервісах, коли кілька сервісів використовують одну й ту саму базу даних.

❌ Order Service → Shared DB ← User Service
                ← Payment Service

Проблеми:

1. Coupling (пов’язаність) — зміна схеми (ALTER TABLE) може зламати інші сервіси, які залежать від тієї ж таблиці. Сервіси перестають бути незалежними.
2. Координований деплой — усі сервіси мають оновитися одночасно
3. Блокування — один сервіс блокує таблиці для інших
4. Немає ізоляції — падіння БД зачіпає усі сервіси. Хоча connection pool retry може пом’якшити короткочасні збої, тривале падіння БД = падіння всієї системи.

---

🟡 Middle Level

Детальні проблеми

// Два сервіси маплять на одну таблицю — зміна колонки ламає обидва:
// UserService.java: @Column("email") — перейменували на "email_address"
// OrderService.java: @Column("email") — зламалося!

1. Schema coupling:

User Service змінив таблицю users
Order Service зламався — очікував стару схему

2. Performance:

Order Service робить важкий запит → блокує таблиці
User Service чекає → latency зростає

3. Data ownership:

Хто володіє таблицею users?
User Service? Order Service?
Хто відповідає за міграції?

Типові помилки

1. Legacy shared DB:

   Моноліт розділили на сервіси, але БД залишили спільною
   → отримали всі мінуси мікросервісів без плюсів
   

---

🔴 Senior Level

Міграція зі Shared DB

Strangler pattern:

1. Створити нову БД для кожного сервісу
2. Dual write → писати в обидві БД
3. Перенести читання на нову БД
4. Прибрати запис у стару БД
5. Видалити стару БД

Best Practices

✅ Database per Service
✅ API для доступу до даних інших сервісів
✅ Events для реплікації даних

❌ Shared database між сервісами
❌ Прямі JOIN між таблицями різних сервісів

---

🎯 Шпаргалка для співбесіди

Обов’язково знати:

• Shared DB — антипатерн: зміна схеми одного сервісу ламає інші
• Schema coupling: ALTER TABLE може зламати залежні сервіси
• Координований деплой — усі сервіси мають оновитися одночасно
• Блокування: важкий запит одного сервісу блокує таблиці для інших
• Немає ізоляції: падіння БД = падіння всієї системи
• Міграція: Strangler pattern — dual write → перенесення читання → видалення старої БД
• Рішення: Database per Service + API/events для доступу до даних

Часті уточнюючі питання:

• Як мігрувати зі Shared DB? Strangler pattern: створити БД для кожного сервісу → dual write → перенести читання → прибрати стару БД.
• Що таке dual write problem? Якщо запис у стару систему успішний, а в нову — ні, дані розсинхронізуються — рішення: Outbox pattern або CDC.
• Хто володіє таблицею в Shared DB? Ніхто — це проблема, немає відповідального за міграції.
• Чи можна пом’якшити Shared DB? Так — окремі схеми, але це компроміс, не рішення.

Червоні прапорці (НЕ говорити):

• “Shared DB — нормальний підхід для мікросервісів” — ні, це антипатерн
• “Моноліт розділили, БД можна залишити спільною” — ні, отримали мінуси без плюсів
• “JOIN між таблицями сервісів — гарна ідея” — ні, це coupling
• “Schema coupling вирішується документацією” — ні, потрібна архітектурна ізоляція

Пов’язані теми:

• [[13. Що таке патерн Database per Service]]
• [[24. Що таке патерн Strangler Fig]]
• [[3. Як реалізувати розподілені транзакції в мікросервісах]]
• [[1. Що таке патерн Saga і коли його використовувати]]
• [[15. Як організувати комунікацію між мікросервісами]]