Что такое монолит?

Монолит: архитектура, где всё в одном

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

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

# Структура типичного монолитного приложения на Django
my_ecommerce_app/
├── users/
│   ├── models.py
│   ├── views.py
│   ├── urls.py
│   └── serializers.py
├── products/
│   ├── models.py
│   ├── views.py
│   ├── urls.py
│   └── serializers.py
├── orders/
│   ├── models.py
│   ├── views.py
│   ├── urls.py
│   └── serializers.py
├── payments/
│   ├── models.py
│   ├── views.py
│   ├── urls.py
│   └── serializers.py
└── manage.py

# Всё работает в одном процессе
# Когда мы деплоим — деплоим всё приложение целиком

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

1. Простота разработки на ранних этапах

• Не нужно думать о распределённых системах и микросервисах
• Легче отлаживать: всё в одном месте
• Проще рефакторить и изменять код

2. Производительность

• Вызовы функций между модулями быстрые (в памяти)
• Нет overhead сетевых запросов
• Проще оптимизировать базу данных (одна БД)

# В монолите это просто вызов функции (быстро)
from orders.services import create_order
from payments.services import process_payment

order = create_order(user, items)
result = process_payment(order.id, amount)  # Быстрый вызов функции

3. Транзакции и консистентность

• Легко обеспечить ACID транзакции
• Всё в одной БД, нет проблем распределённых транзакций

from django.db import transaction

@transaction.atomic
def create_order_with_payment(user, items, payment_info):
    order = Order.objects.create(user=user)
    OrderItem.objects.bulk_create([...])
    Payment.objects.create(order=order, status="completed")
    # Если что-то упадёт — откатываем всё

4. Меньше операционной сложности

• Один процесс для мониторинга
• Один логи файл (или один инстанс)
• Проще деплойка на начальных этапах

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

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

# Проблема: мы не можем масштабировать части приложения отдельно
# Приложение растёт, становится медленным
# Единственный способ масштабирования — вертикальный (более мощные серверы)
# или горизонтальный (копировать весь монолит)

# Если нагрузка исходит от модуля payments, мы не можем просто
# добавить инстанс payments — нужно добавить весь монолит

2. Зависимости между модулями

• Модули становятся тесно связаны друг с другом
• Сложно что-то менять, не сломав другое
• Со временем образуется спагетти-код

# Плохо: циклические зависимости и тесная связь
# users.views использует products.services
# products.services использует orders.models
# orders.models использует users.models
# Рефакторинг одного модуля затрагивает всех

3. Сложность развертывания

• Даже маленькое изменение в одном модуле требует пересборки и переразвертывания всего приложения
• Риск: баг в модуле payments может сломать весь сервис
• Downtime при развертывании

4. Разнородные технологии

• Когда приложение растёт, может быть нужны разные технологии
• В монолите сложно использовать разные языки или фреймворки
• Если весь проект на Python и вдруг для одного модуля нужна нота — проблемы

5. Командная работа

• Команды конфликтуют при работе с одним кодбейсом
• Merge conflicts
• Сложнее разделить ответственность

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

# МОНОЛИТ: всё в одном приложении
Django REST API
├── Users Module
├── Products Module
├── Orders Module
├── Payments Module
└── Notifications Module
↓ Deploy
Django Instance (один или несколько копий)

# МИКРОСЕРВИСЫ: разные приложения
Users Microservice (FastAPI)
Products Microservice (Flask)
Orders Microservice (Django)
Payments Microservice (Node.js)
Notifications Microservice (FastAPI)
↓ Каждый деплоится отдельно

Когда монолит уместен

• MVP (Minimum Viable Product): нужно быстро вывести продукт
• Маленькие команды: 5-10 разработчиков
• Простой продукт: нет сложных требований к масштабируемости
• Стартапы: нужна скорость, а не идеальная архитектура
• CRUD приложения: стандартные операции с данными

Когда переходить на микросервисы

• Команда растёт (20+ разработчиков)
• Разные части приложения имеют разные нагрузки
• Нужна развертываемость отдельных компонентов
• Используются разные технологии

Заключение

Монолит — это идеальная архитектура для начала. Это просто, быстро в разработке и имеет хорошую производительность. Но при росте приложения он становится препятствием для масштабирования и разработки. Большинство успешных компаний (Amazon, Netflix, Uber) начинали с монолита и переходили на микросервисы когда это стало необходимо. Это не ошибка архитектуры — это естественная эволюция.