Какие критерии вы бы использовали для разделения системы на микросервисы?

Определение

Разделение на микросервисы — это разбиение системы на автономные компоненты, каждый из которых реализует свою бизнес-способность и может разрабатываться/деплоиться независимо.

Ключевые критерии декомпозиции

1. Бизнес-границы (bounded context)

   • Сервис соответствует одному домену/поддомену: “оплата”, “доставка”, “каталог”.

   • Внутри сервиса термины и правила не противоречат сами себе.

2. Владение данными

   • У сервиса есть свой источник истины (своя схема/БД/таблицы).

   • Другие сервисы не “ходят” напрямую в его БД, а используют API/ивенты.

3. Слабая связанность изменений

   • Если фича часто требует правок сразу в 3–4 компонентах, граница проведена плохо.

   • Цель — чтобы большинство изменений были локальными.

4. Независимый деплой

   • Сервис можно выкатывать без обязательного “синхронного” релиза соседей.

   • Контрактная совместимость важнее общих библиотек “на все случаи”.

5. Разные требования к нагрузке и масштабированию

   • Если один участок системы требует x10 CPU, а другой — нет, это аргумент к разделению.

   • Но “разная нагрузка” — не повод дробить слишком мелко.

6. Разные требования к надежности и критичности

   • Критичный сервис может требовать других SLA, алертов, изоляции отказов.

7. Командные границы

   • Один сервис — одна команда (в идеале): меньше координации, быстрее релизы.

   • Если сервисом владеют “все”, он обычно становится монолитом внутри микросервисов.

Типовые ошибки

• Делить “по слоям” (users-api, users-db, users-worker) вместо бизнес-способностей.

• Делать сервисы слишком маленькими до появления реальной необходимости.

• Общая база данных на всех сервисов → формально микросервисы, фактически монолит.

Практический мини-пример (как проверять границу)

# Плохой сигнал: сервис "Order" напрямую читает таблицы "Payments"
# Вместо этого — запрос к API платежей или событие PaymentCompleted.

payment_status = payments_client.get_status(order.payment_id)  # ок
# payment_status = db.query("select ... from payments")        # плохо

Вывод

Декомпозировать на микросервисы стоит по бизнес-границам + владению данными + независимости изменений, а не ради “модной архитектуры”.