Какой архитектурный подход противоположен паттерну «Database per Service» в микросервисах?

«Какой архитектурный подход противоположен паттерну «Database per Service» в микросервисах?» — вопрос из категории Архитектура, который задают на 10% собеседований Java Разработчик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Противоположный подход — Shared Database (Общая база данных), когда несколько микросервисов работают с одной и той же базой данных.

Сравнение подходов: Критерий Database per Service Shared Database
Связанность Низкая (сервисы независимы) Высокая (изменение схемы БД затрагивает многие сервисы)
Согласованность Сложная (требует саг или событий) Простая (ACID-транзакции)
Масштабирование Горизонтальное (по сервисам) Ограниченное (масштабирование самой БД)

Проблемы Shared Database:

  1. Хрупкость: Изменение схемы таблицы может сломать несколько сервисов.
  2. Блокировки: Высокая конкуренция за ресурсы БД от разных сервисов.
  3. Нарушение инкапсуляции: Сервисы знают внутреннюю структуру данных друг друга.

Современные альтернативы для решения проблем распределенных данных:

  • Паттерн Saga: Оркестрация или хореография длинных транзакций через события.
  • CQRS (Command Query Responsibility Segregation): Разделение моделей для записи (команды) и чтения (запросы).
  • Event Sourcing: Хранение состояния как последовательности событий.