# 11. Монолит и микросервисы

Как выбирать между modular monolith и microservices, когда split оправдан, какие цены несёт распределение и почему сервис не равен границе.

- **Author:** Фёдор Чищин
- **Level:** advanced
- **Reading time:** ~25 минут чтения
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/ru/learn/software-architect-11-monolith-microservices

---

## 1. Главная идея

Микросервисы покупают независимость ценой распределённой сложности. Если независимость не нужна, цена может быть лишней.

### Сервис — это организационная единица

> Отдельный офис полезен, когда у команды есть своя работа, ритм и ответственность. Если все всё равно сидят на одном созвоне, стены не помогают.

Микросервис оправдан, когда контекст имеет отдельный жизненный цикл, команду-владельца, нагрузочный профиль, требования безопасности или релизный ритм. Просто вынести код в отдельный deployable unit недостаточно.

**Modular monolith** часто лучше на ранней стадии: одна кодовая база и deployment, но строгие внутренние модули, публичные interfaces, запрет циклических зависимостей и ясный ownership.

### Распределение добавляет операционную цену

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

Микросервисы требуют service discovery, observability, network security, backward-compatible contracts, distributed tracing, deployment orchestration, incident response, data ownership и SRE-практики. Это не минус, если есть причина. Это цена.

Архитектор должен честно спросить: какая боль исчезнет после split и какая новая боль появится?

## 2. Пример и антипример

Хороший split уменьшает координацию. Плохой split создаёт больше согласований, чем было до него.

### Пример: выделить billing

> Касса, бухгалтерия и склад связаны, но у бухгалтерии свои правила, аудит и ответственность.

Billing имеет отдельные compliance-требования, audit trail, интеграции с payment providers и команду-владельца. Его можно выделить в сервис с собственными данными и контрактами: invoices, subscriptions, payment events.

Такой split понятен: он защищает домен с высокой ценой ошибки и отдельным темпом изменений.

### Антипример: микросервис на каждую таблицу

> Если каждая полка склада стала отдельным магазином, покупателю придётся пройти десять касс ради одного заказа.

Команда делает `users-service`, `profiles-service`, `addresses-service`, `roles-service`, но любой use case требует вызовов всех четырёх. Данные всё равно связаны, релизы всё равно совместные, а latency и debugging стали хуже.

Это distributed monolith: сервисы есть, независимости нет.

#### Самопроверка

- Какая команда будет владеть сервисом?
- Может ли сервис релизиться независимо?
- Чьи данные он владеет?
- Какие новые operational responsibilities появятся после split?

Следующий модуль: [Sync и async](./software-architect-12-sync-async).