Как относишься к монолитным системам?

Отношение к монолитным системам

Как senior разработчик с 10+ лет опыта, я вижу монолитные системы не как врага, а как инструмент с четкими trade-offs. Нет универсально правильного подхода — выбор зависит от контекста.

Плюсы монолита

1. Простота разработки и развертывания

• Единая кодовая база — легче ориентироваться
• Один процесс — проще отладка, профилирование
• Одна БД — гарантия ACID транзакций, консистентность
• Развертывание одной командой — git push → все сервисы обновлены

# Монолит: одна функция вызывает другую
def create_order(user_id, items):
    # Проверка пользователя
    user = get_user(user_id)
    
    # Создание заказа (та же БД, та же транзакция)
    order = create_order_in_db(user, items)
    
    # Обновление инвентаря
    update_inventory(items)
    
    # Отправка email
    send_confirmation_email(user.email)
    
    return order  # Всё в одной транзакции или откаты вместе

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

• Нет network latency — вызовы функций быстрее чем HTTP
• Shared memory — кэширование дешевле
• Оптимизация в пределах одного процесса

# Монолит: прямой доступ к данным
@lru_cache(maxsize=1000)
def get_user_with_orders(user_id):
    # Одна операция в памяти
    return db.query(User).filter_by(id=user_id).with_joinedload(User.orders)

# Микросервисы: несколько запросов
async def get_user_with_orders(user_id):
    user = await user_service.get(user_id)
    orders = await order_service.get_by_user(user_id)
    return {**user, orders}

3. Легче обеспечить консистентность данных

# Одна транзакция на весь процесс
def transfer_money(from_account, to_account, amount):
    try:
        with db.transaction():
            # Если упадет на любом шаге — всё откатит
            from_account.balance -= amount
            to_account.balance += amount
            log_transaction(from_account, to_account, amount)
            notify_user(from_account.user_id)  # Всё в одной транзакции
    except Exception:
        # Автоматический rollback всего
        raise

Минусы монолита

1. Масштабирование

• Масштабируется весь код, не отдельные компоненты
• Если нужно усилить обработку платежей, приходится масштабировать все

# Монолит: один процесс
# Если требуется 10x для платежей, масштабируем ВСЕ
# CPU растет на 10x, память на 10x

# Микросервисы: отдельный сервис платежей
# Масштабируем только платежный сервис
payment_service_instances = 10
other_services_instances = 2

2. Развитие независимо

• Сложно работать параллельно 20 разработчикам на один монолит
• Конфликты в git
• Один глупый баг может упасть все
• Развертывание требует всех компонентов (А работает, Б работает, В упал)

# Монолит: все в одном
# Разработчик A меняет payment.py
# Разработчик B меняет inventory.py
# Конфликты слияния, нужно тестировать все вместе

# Микросервисы: независимые репозитории
# payment_service/ - B может развертывать независимо
# inventory_service/ - A может развертывать независимо

3. Технологический долг

# Монолит: привязан к технологиям
# Django + SQLAlchemy + Redis (все вместе)
# Сложно менять части или обновляться

# Микросервисы: могут использовать разные стеки
# payment_service: Go + PostgreSQL (высокая производительность)
# recommendation_service: Python + ML stack
# notification_service: Node.js + FastAPI (быстрое развитие)

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

1. MVP и стартапы

# Для MVP нужна скорость, не масштабируемость
# Монолит позволяет быстро что-то выбросить в продакшен

# При 10k пользователей монолит работает идеально
# Один инстанс Django = достаточно

2. Простые приложения

# Блог, каталог, CMS
# Нет сложной бизнес-логики
# Монолит полностью оправдан

from fastapi import FastAPI
app = FastAPI()

@app.get("/posts")
def get_posts():
    return db.query(Post).all()

@app.post("/posts")
def create_post(post: PostCreate):
    return db.add(post)

3. Когда сервис критичен на 100%

# Если даже 1 микросервис упал — система не работает
# Например, критичный платежный шлюз

# Монолит + хорошее логирование + alerting = надежнее
# чем 5 микросервисов с синхронизацией состояния

# Одна база данных + одна транзакция = гарантия

Когда нужны микросервисы

1. Масштабирование по разным осям

# E-commerce: поиск масштабируется по другим законам
# Search (Elasticsearch, 10 инстансов)
# Products (PostgreSQL, 3 инстанса)
# Orders (PostgreSQL, 5 инстансов)
# Notifications (Redis Queue, 2 инстанса)

2. Разные технологические требования

# Real-time чаты требуют WebSocket
# ML требует Python + CUDA GPU
# Видео требует Go + libvpx

# Монолит заставляет обвязывать всё одной технологией

3. Большая команда (>30 разработчиков)

# Конфликты слияния становятся узким местом
# Команда по платежам работает независимо
# Команда по поиску работает независимо
# Меньше blocking dependencies

Гибридный подход: Модульный монолит

# Не спешим в микросервисы, но готовимся

# Структура проекта
src/
  payments/          # Четкие границы
    models.py
    service.py
    handlers.py
  inventory/         # Четкие границы
    models.py
    service.py
    handlers.py
  notifications/     # Четкие границы
    service.py

# Проблема: никакого import payments.service.foo из других модулей
# Общение через event bus

from events import EventBus

# payments/service.py
class PaymentService:
    def process_payment(self, order_id):
        # Логика платежа
        EventBus.publish('payment.completed', order_id)

# notifications/service.py
class NotificationService:
    def setup(self):
        EventBus.subscribe('payment.completed', self.send_receipt)
    
    def send_receipt(self, order_id):
        # Отправить уведомление
        pass

Моя позиция

За монолит:

• На ранних стадиях — монолит дает скорость
• Для простых CRUD приложений — монолит оптимален
• Консистентность и простота > масштабируемость на MVP

Против микросервисов:

• Микросервисы добавляют сложность на 10x
• Распределённые транзакции сложны (saga, eventual consistency)
• Требуют DevOps expertise (Kubernetes, логирование, трейсинг)

Идеальный путь:

1. Начинаем с модульного монолита (четкая архитектура)
2. Следим за метриками (задержки, CPU, памяь)
3. При масштабировании вытаскиваем сервис за сервисом
4. Начинаем с асинхронных очередей (RabbitMQ, Celery)
5. Только если нужно — микросервисы

Никогда:

• Не начинаешь с микросервисов
• Не используешь микросервисы для разделения команд (можно с git branches)
• Не вводишь микросервисы пока боль реально не почувствуешь

Монолит — отличный инструмент, если правильно его использовать. Проблема не в монолите, а в плохой архитектуре.