Должен ли паттерн Database per service присутствовать в микросервисной архитектуре

Database per Service в микросервисной архитектуре

Это один из самых спорных паттернов микросервисной архитектуры. Ответ не однозначный: должен присутствовать, но с условиями и исключениями.

Что такое Database per Service

Паттерн, где каждый микросервис имеет свою отдельную базу данных. Это обеспечивает полную независимость сервисов на уровне хранилища.

Преимущества Database per Service

1. Независимость сервисов

# Service 1 (Orders) - своя БД
engine_orders = create_engine("postgresql://user:pass@orders-db/orders_db")

class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    user_id = Column(Integer)
    amount = Column(Float)

# Service 2 (Users) - своя БД, полностью независимая
engine_users = create_engine("postgresql://user:pass@users-db/users_db")

class User(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True)
    email = Column(String)

# Если users-db упадёт, orders-service продолжит работу!

2. Масштабируемость

# Orders Service может иметь больше ресурсов
engine_orders = create_engine(
    "postgresql://orders-db-cluster/orders_db",
    pool_size=50,
    max_overflow=100
)

# Users Service использует меньше
engine_users = create_engine(
    "postgresql://users-db/users_db",
    pool_size=10
)

3. Технологическая гибкость

# Orders Service - PostgreSQL (транзакции важны)
orders_db = PostgreSQL()

# Analytics Service - MongoDB (гибкая схема)
from pymongo import MongoClient
analytics_db = MongoClient()["analytics"]

# Cache Service - Redis
from redis import Redis
cache_db = Redis()

4. Независимые миграции

-- Orders Service может обновить schema
ALTER TABLE orders ADD COLUMN status VARCHAR(50);

-- Это НЕ влияет на Users Service

Недостатки Database per Service

1. Сложность распределённых транзакций

# Проблема: создать заказ И отметить пользователя активным
# Но они в разных БД!

@app.post("/orders")
async def create_order(order_data, user_id: int):
    try:
        # Шаг 1: создать заказ
        order = await orders_db.create_order(order_data)
        
        # Шаг 2: обновить пользователя
        # НО если упадёт - заказ уже создан! Inconsistency!
        await users_db.mark_active(user_id)
    except Exception:
        # Что делать? Откатить заказ?
        pass

Решение: Saga паттерн

class OrderSaga:
    async def execute(self, order_data, user_id):
        try:
            order = await self.orders_service.create(order_data)
            await self.user_service.mark_active(user_id)
            await self.payment_service.charge(order.amount)
            return {"status": "success"}
        except Exception:
            # Компенсирующие транзакции (откат)
            await self.orders_service.cancel(order.id)
            await self.payment_service.refund(order.amount)
            return {"status": "failed"}

2. Сложность JOIN операций

# Нужны заказы пользователя с информацией о пользователе
# Но в разных БД!

# Неправильно (неэффективно):
@app.get("/users/{user_id}/orders")
async def get_user_orders(user_id: int):
    user = await users_db.get(user_id)  # БД 1
    orders = await orders_db.get_user_orders(user_id)  # БД 2
    
    # Объединяем в приложении
    return [{**o, "user_email": user.email} for o in orders]

Решение: Event-driven синхронизация

# Orders Service хранит денормализованные данные
class OrderProjection(Base):
    __tablename__ = "orders_with_user"
    order_id = Column(Integer, primary_key=True)
    user_email = Column(String)  # Копия из Users!
    amount = Column(Float)

# Users Service отправляет события
from kafka import KafkaProducer
producer = KafkaProducer(bootstrap_servers=["kafka:9092"])

event = {"type": "user.updated", "user_id": 123, "email": "new@mail.com"}
producer.send("user_events", event)

# Orders Service слушает и обновляет свою копию
from kafka import KafkaConsumer
consumer = KafkaConsumer("user_events", bootstrap_servers=["kafka:9092"])

for message in consumer:
    event = message.value
    # Обновить denormalized данные
    await orders_db.update_user_email(event["user_id"], event["email"])

3. Сложность отладки

# С одной БД: быстро найти проблему
SELECT * FROM orders WHERE user_id = 123;

# С несколькими БД: нужно проверить:
# - Логи Orders Service
# - Логи Users Service
# - Логи Payment Service
# - Статус очереди сообщений
# - Данные в каждой БД
# - Состояние Saga

# На отладку уходит в 10x больше времени!

4. Inconsistency

# Это возможно:
SELECT * FROM orders WHERE user_id = 123;  -- 5 заказов
SELECT user_orders_count FROM users WHERE id = 123;  -- 3

# Данные рассинхронизировались!
# Нужна система мониторинга и reconciliation

Когда использовать Database per Service

✅ ИСПОЛЬЗУЙ, ЕСЛИ:

# 1. Сервисы полностью независимые
class OrdersService:  # Своя логика
    pass

class RecommendationsService:  # Не связана с заказами
    pass

# 2. Разные технологические стеки
# Orders: PostgreSQL (ACID)
# Analytics: MongoDB (гибкая схема)
# Search: Elasticsearch (полнотекстовый)

# 3. Разные требования к масштабируемости
# Orders: большие нагрузки
# Settings: малые нагрузки

# 4. Разные требования к консистентности
# Orders: строгая ACID
# Analytics: eventual consistency OK

❌ НЕ ИСПОЛЬЗУЙ, ЕСЛИ:

# 1. Много тесных связей между сервисами
# Частые транзакции между ними
# → Лучше монолит или shared database

# 2. Команда маленькая
# Database per Service добавляет операционную сложность
# Нужны знания распределённых систем

# 3. Требуется строгая ACID везде
# Saga паттерны - это не транзакции
# Могут быть ошибки согласованности

# 4. Данные часто реиспользуются
# Много синхронизации → много проблем

Гибридный подход (РЕКОМЕНДУЕТСЯ)

# Не все сервисы должны иметь отдельные БД:

# Группа 1: Независимые, разные БД
# - Orders Service (PostgreSQL)
# - Users Service (PostgreSQL)
# - Analytics Service (MongoDB)

# Группа 2: Связанные, одна БД
# - Settings Service
# - Notifications Service
# Они часто обращаются друг к другу

# Группа 3: Вспомогательные, shared cache
# - Cache Service (Redis)
# - Session Service (Redis)
# Используют один Redis для простоты

Пример реальной архитектуры

# Orders Service - отдельная БД
class OrdersService:
    async def create_order(self, order_data):
        order = await self.db.create(order_data)
        
        # Запустить saga для консистентности
        await self.saga.execute(order)
        
        # Опубликовать событие
        await self.event_bus.publish("order.created", order)
        return order

# Users Service - отдельная БД
class UsersService:
    async def update(self, user_id, data):
        user = await self.db.update(user_id, data)
        await self.event_bus.publish("user.updated", user)
        return user

# Orders Service слушает события Users для синхронизации
class OrdersEventHandler:
    async def on_user_updated(self, event):
        # Обновить свои denormalized данные
        await self.db.sync_user_data(event.user_id, event.data)

Выводы

Database per Service должен присутствовать в микросервисной архитектуре, но:

1. НЕ везде — только для независимых сервисов
2. С правильными паттернами — Saga, Event-driven, DDD
3. С опытом команды — нужны знания распределённых систем
4. Гибридный подход — некоторые сервисы могут делить БД
5. С мониторингом — нужна система отслеживания консистентности

Практический совет: Начни с Database per Service для явно независимых сервисов. Добавляй Saga паттерны для критических операций. Используй Event Sourcing для синхронизации. Мониторь консистентность данных.