🤨 Должна ли у микросервиса всегда быть своя БД? 🤨
Да! Нет.
Хороший вопрос с подвохом для собеседования.
👉 Начнём с того, что есть паттерн проектирования микросервисов — Database per Service.
Он утверждает:
«каждый сервис работает только со своей БД, чужие данные не трогаем».
Зачем это нужно:
+ уменьшает связанность,
+ даёт независимость сервисов,
+ при падении БД ломается только один сервис,
+ одно изменение в данных не «роняет» соседние сервисы.
Но в реальной жизни всё чуть сложнее...
1️⃣ Чистое соблюдение Database per Service
Так бывает.
У каждого микросервиса — своя СУБД или хотя бы свой кластер.
✅ Максимум изоляции.
❌ Но: больше инфраструктуры, мониторинга, бэкапов и миграций.
2️⃣ Несколько схем внутри одной СУБД
Распространённое решение.
Одна база (например, PostgreSQL), но для каждого сервиса отдельная схема.
✅ Разграничение доступа и независимость структур данных.
✅ Меньше операционных проблем.
❌ Всё равно сохраняется определённая связанность.
3️⃣ Одна база на несколько сервисов
Иногда команда разработки решает: «так удобнее».
Особенно если сервисы тесно связаны по данным, то разделение породит лишние транзакционные цепочки и задержки.
✅ Просто и эффективно.
❌ Формально это уже не «чистые» микросервисы.
👉 Итого
Database per Service — это паттерн, а не жёсткое правило.
Его цель — изоляция и независимость сервисов.
Но на практике уместны разные подходы: от «чистого» варианта до схем в одной БД или даже общей базы на несколько сервисов.
Задача аналитиков и архитекторов — найти баланс между изоляцией, удобством сопровождения и требованиями бизнеса 🙌
#АрхитектураGA
Да! Нет.
Хороший вопрос с подвохом для собеседования.
👉 Начнём с того, что есть паттерн проектирования микросервисов — Database per Service.
Он утверждает:
«каждый сервис работает только со своей БД, чужие данные не трогаем».
Зачем это нужно:
+ уменьшает связанность,
+ даёт независимость сервисов,
+ при падении БД ломается только один сервис,
+ одно изменение в данных не «роняет» соседние сервисы.
Но в реальной жизни всё чуть сложнее...
1️⃣ Чистое соблюдение Database per Service
Так бывает.
У каждого микросервиса — своя СУБД или хотя бы свой кластер.
✅ Максимум изоляции.
❌ Но: больше инфраструктуры, мониторинга, бэкапов и миграций.
2️⃣ Несколько схем внутри одной СУБД
Распространённое решение.
Одна база (например, PostgreSQL), но для каждого сервиса отдельная схема.
✅ Разграничение доступа и независимость структур данных.
✅ Меньше операционных проблем.
❌ Всё равно сохраняется определённая связанность.
3️⃣ Одна база на несколько сервисов
Иногда команда разработки решает: «так удобнее».
Особенно если сервисы тесно связаны по данным, то разделение породит лишние транзакционные цепочки и задержки.
✅ Просто и эффективно.
❌ Формально это уже не «чистые» микросервисы.
👉 Итого
Database per Service — это паттерн, а не жёсткое правило.
Его цель — изоляция и независимость сервисов.
Но на практике уместны разные подходы: от «чистого» варианта до схем в одной БД или даже общей базы на несколько сервисов.
Задача аналитиков и архитекторов — найти баланс между изоляцией, удобством сопровождения и требованиями бизнеса 🙌
#АрхитектураGA