🟢 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? Да — отдельные schemas, но это компромисс, не решение.

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

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

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

• [[13. Что такое паттерн Database per Service]]
• [[24. Что такое паттерн Strangler Fig]]
• [[3. Как реализовать распределённые транзакции в микросервисах]]
• [[1. Что такое паттерн Saga и когда его использовать]]
• [[15. Как организовать коммуникацию между микросервисами]]