Когда используешь монолит?

Когда используешь монолит?

Монолит — архитектура, где всё приложение — один единый процесс. Вопреки тренду на микросервисы, монолит по-прежнему — отличный выбор в большинстве случаев.

Когда монолит — правильный выбор

1. MVP и стартапы (САМЫЙ ЧАСТЫЙ СЛУЧАЙ)

Этап: Идея → MVP → Первые пользователи
Время на маркет: КРИТИЧНО
Данные: Нет опыта

Почему монолит:

• ✅ Быстро развернуть
• ✅ Просто деплоить (один jar файл)
• ✅ Легко отлаживать
• ✅ Единая база данных
• ✅ Нет сложности распределённых систем

// Стартап стек
// Spring Boot монолит
// PostgreSQL
// Single deployment
// Готово за 2-3 недели

2. Приложение меньше 50K строк кода

Монолит остаётся простым и управляемым, если:

• Одна команда разработки (5-15 человек)
• Понятная структура слоёв
• Хорошие модульные границы внутри

// Пример хорошей модульной структуры в монолите
src/main/java/com/app/
├── users/
│   ├── controller/
│   ├── service/
│   ├── repository/
│   └── dto/
├── orders/
│   ├── controller/
│   ├── service/
│   ├── repository/
│   └── dto/
├── payments/
│   ├── controller/
│   ├── service/
│   └── repository/
└── shared/
    └── config/

3. Требования к консистентности данных ВЫСОКИЕ

Монолит даёт ACID транзакции легко:

@Service
public class OrderService {
    
    @Transactional  // Одна транзакция БД
    public void createOrder(OrderRequest request) {
        // 1. Проверяем инвентарь
        Inventory inventory = inventoryRepo.findByProductId(request.getProductId());
        if (inventory.getQuantity() < request.getQuantity()) {
            throw new OutOfStockException();
        }
        
        // 2. Создаём заказ
        Order order = new Order(request);
        Order saved = orderRepo.save(order);
        
        // 3. Резервируем инвентарь
        inventory.reserve(request.getQuantity());
        inventoryRepo.save(inventory);
        
        // 4. Если ЛЮБАЯ ошибка — всё откатится автоматически
    }
}

В микросервисах нужен SAGA pattern — сложнее и медленнее.

4. Нет различных требований к масштабированию разных частей

Если всё растёт пропорционально — монолит масштабируется просто:

// Монолит
Server 1: Spring Boot + PostgreSQL
Server 2: Spring Boot + PostgreSQL (Read replica)
Server 3: Spring Boot + PostgreSQL (Read replica)
// Load Balancer распределяет трафик

// Все компоненты растут вместе

5. Командная структура небольшая или одна команда

Монолит — естественный выбор для:

• Одна команда ← Монолит, экономим на overhead'е
• 2-3 маленькие команды ← Всё ещё монолит с модульной границей
• 5+ независимых команд ← Пора думать о микросервисах

Конвэй'с Закон: Архитектура системы отражает организационную структуру команды.

Когда НЕ используешь монолит

❌ Система уже 500K+ строк кода
❌ 10+ независимых команд
❌ Разные требования к масштабированию:
   - API может быть 100K req/sec
   - Workers могут быть 100 req/sec
   - Admin может быть 10 req/sec
❌ Разные языки программирования
❌ Разные SLA по скорости deploy
❌ Политика: каждая команда независима

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

Признаки проблем с монолитом:

// 1. Deployment pain
// Один baggy commit ломает всё
@Service
class UserService { /* 5000 строк */ }

// 2. Scaling bottleneck
// Вся система масштабируется, хотя нужен только один компонент

// 3. Team friction
// Две команды мешают друг другу в коде

// 4. Technology heterogeneity
// Нужен Node.js для реал-тайма, но весь стек Java

// 5. Database coupling
// Все компоненты в одной БД — сложно разрабатывать

Реальный пример: Netflix

2008: Монолит на Java

• Одна война за восстановление от сбоя базы данных
• Осознание необходимости масштабируемости

Решение: Микросервисы

• 600+ микросервисов
• Полная независимость команд
• Chaos engineering

Вывод: Netflix нужны микросервисы. Вам? Почти определённо нет.

Мой совет

🎯 Стартайте с монолита ВСЕГДА, если:

• Нет крайне высоких требований к масштабированию
• Команда меньше 10 человек
• Нет жёстких требований к разным технологиям

Почему?

1. Монолит проще понять и поддерживать
2. Легче найти баги
3. Развёртывание намного проще
4. Транзакции работают из коробки
5. Мониторинг проще

Потом, если нужно — рефакторить на микросервисы.

Статистика

По опросам разработчиков:

• 70% приложений в production — монолиты
• 25% — гибридные (монолит + несколько микросервисов)
• 5% — полный микросервис-ориентированный стек

Итог: Монолит — первый и предпочтительный выбор. Микросервисы — когда монолит перестал работать.