[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-mikroservisy-database-per-service-ili-shared-database-kakoy-podkhod-vybrat":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":16,"progress":17,"seo":18},910,"database-per-service-ili-shared-database-kakoy-podkhod-vybrat",23,"mikroservisy","Микросервисы","🔗","Database per Service или Shared Database -- какой подход выбрать?","Database per Service — это принцип, при котором каждый микросервис владеет собственным хранилищем данных. Shared Database — общая БД для нескольких сервисов. Правильный подход для микросервисов — Database per Service, Shared Database допустим только как временное решение при миграции.\n\n### Database per Service\n\n```\n┌──────────────┐  ┌──────────────┐  ┌──────────────┐\n│ Payment      │  │ Customer     │  │ Notification │\n│ Service      │  │ Service      │  │ Service      │\n└──────┬───────┘  └──────┬───────┘  └──────┬───────┘\n       │                 │                 │\n┌──────▼───────┐  ┌──────▼───────┐  ┌──────▼───────┐\n│ PostgreSQL   │  │ PostgreSQL   │  │  MongoDB     │\n│ (payments)   │  │ (customers)  │  │ (notif.)     │\n└──────────────┘  └──────────────┘  └──────────────┘\n```\n\n| Критерий | Database per Service | Shared Database |\n|---|---|---|\n| Связность | Слабая — сервисы независимы | Сильная — общая схема |\n| Хранилище | Оптимальное для каждого сервиса | Единое для всех |\n| JOIN-запросы | Невозможны между базами | Простые JOIN |\n| Транзакции | Saga (eventual consistency) | ACID |\n| Масштабирование БД | Независимое | Общее |\n| Отказоустойчивость | Сбой одной БД не влияет на другие | БД — единая точка отказа |\n| Дублирование данных | Неизбежно | Нет |\n\n### Компромисс -- Schema per Service\n\n```sql\n-- Каждый сервис имеет свою схему в одной БД\nCREATE SCHEMA payment_service;\nCREATE SCHEMA customer_service;\n\n-- Сервисы обращаются ТОЛЬКО к своей схеме\nGRANT USAGE ON SCHEMA payment_service TO payment_svc_user;\nREVOKE ALL ON SCHEMA customer_service FROM payment_svc_user;\n```\n\n### Рекомендации\n\n- Начинайте с Database per Service — это правильный подход для микросервисов.\n- Если нужны данные другого сервиса — запрашивайте через API, а не через прямой доступ к БД.\n- Shared Database — только как временное решение при миграции с монолита (паттерн Strangler Fig).\n- Для отчётов и аналитики — используйте CQRS с отдельной read-моделью.\n\n> **На собеседовании:** рекомендуйте Database per Service как целевой подход и объясните, почему: слабая связность и независимость. Но покажите, что понимаете цену: Saga вместо ACID и невозможность JOIN. Упомяните Schema per Service как промежуточный шаг.","","middle",[15],"microservices",[],null,{"title":19,"description":20,"ogTitle":19,"ogDescription":21,"keywords":22,"schemaAnswer":23,"featuredSnippetReady":24},"Database per Service или Shared Database -- какой подход выб — Gymterview","Database per Service — это принцип, при котором каждый микросервис владеет собственным хранилищем данных. Shared Database — общая БД для нескольких сервисов. Пр","Database per Service — это принцип, при котором каждый микросервис владеет собственным хранилищем данных. Shared Databas",[15,13],"Database per Service — это принцип, при котором каждый микросервис владеет собственным хранилищем данных. Shared Database — общая БД для нескольких сервисов. Правильный подход для микросервисов — Database per Service, Shared Database допустим только как временное решение при миграции.",true]