Что такое монолитный сервис?

Что такое монолитный сервис

Определение

Монолитный сервис (монолитная архитектура) — это архитектура приложения, где все функции и компоненты объединены в одном кодовом проекте и развёртываются как единое целое. Это противоположность микросервисной архитектуре.

Структура монолитного приложения

┌────────────────────────────────────┐
│     Монолитное приложение         │
├────────────────────────────────────┤
│ User Module (аутентификация)       │
│ Product Module (каталог)           │
│ Order Module (заказы)              │
│ Payment Module (платежи)           │
│ Notification Module (уведомления)  │
│ Analytics Module (аналитика)       │
├────────────────────────────────────┤
│        Единая БД                  │
└────────────────────────────────────┘
         ↓ (Развёртывание как одно целое)
       Сервер

Характеристики монолита

1. Единственное развёртывание

• Все модули развёртываются вместе
• Изменение в одном модуле требует переразвёртывания всего приложения
• Нельзя обновить одну функцию — нужно обновить весь сервис

2. Единая кодовая база

• Один Git репозиторий
• Один язык программирования
• Общие зависимости

Пример:

my-store-app/
├── users/
│   ├── models.py
│   ├── controllers.py
│   └── services.py
├── products/
│   ├── models.py
│   └── controllers.py
├── orders/
│   └── ...
├── requirements.txt (все зависимости вместе)
└── main.py (точка входа)

3. Единая БД

• Все модули используют одну БД
• Нет разделения данных
• Проще управлять транзакциями

Преимущества монолита

• Простота разработки — начинающим разработчикам легче начать
• Проще отладка — всё в одном месте, легко отследить ошибки
• Единообразность — одна технология, один стиль кода
• Проще транзакции — ACID гарантии внутри одной БД
• Проще развёртывание — один артефакт (exe, jar, docker image)
• Лучше производительность — нет сетевых задержек между сервисами
• Дешевле инфраструктура — один сервер, одна БД

Недостатки монолита

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

• Нельзя масштабировать отдельные модули
• Если перегружена функция заказов, нужно масштабировать весь сервис

2. Зависимость развёртывания

• Исправление бага в пользователях требует переразвёртывания всего приложения
• Риск — если тесты не прошли, весь сервис упадёт

3. Сложность с ростом

• После 10+ модулей монолит становится трудно управлять
• Разработчики натыкаются друг на друга
• Медленнее сборка и тесты

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

• Все модули на одном языке
• Нельзя использовать Python для аналитики и Java для платежей

5. Отказоустойчивость

• Крах одного модуля = крах всего приложения

Когда использовать монолит

✅ Подходит:

• Стартап в начале (MVP)
• Небольшие проекты (1-3 разработчика)
• Простые системы
• Внутренние приложения
• Когда нет больших требований к масштабируемости

❌ Не подходит:

• Большие системы с множеством функций
• Высоконагруженные приложения (миллионы пользователей)
• Когда части системы масштабируются независимо
• Когда нужна гибкость в выборе технологий

Монолит vs Микросервисы

Вывод для BA

Монолит — это правильный выбор для начальной фазы проекта. Однако если приложение растёт и требует масштабирования, в будущем может понадобиться миграция на микросервисы.

Лучший подход: начни с монолита, а когда система вырастет — рефакторь в микросервисы постепенно. Именно этот путь прошли Netflix, Amazon, Uber.