Когда не нужно использовать микросервисную архитектуру?

Когда НЕ нужна микросервисная архитектура

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

1. Небольшой проект или MVP

Для стартапа или MVP микросервисы — избыточная сложность:

// Монолит достаточен для начального этапа
@SpringBootApplication
public class ShopApplication {
    public static void main(String[] args) {
        SpringApplication.run(ShopApplication.class, args);
    }
}

@RestController
@RequestMapping("/api")
public class ProductController { /* ... */ }

@RestController
@RequestMapping("/api")
public class OrderController { /* ... */ }

Проблемы микросервисов в этом случае:

• Лишние затраты на развертывание и мониторинг
• Сложность координации между сервисами
• Задержки на сетевых вызовах

2. Маленькая команда разработчиков

Микросервисная архитектура требует опыта и масштабной команды:

Монолит (5 разработчиков):
- Одна кодовая база
- Общее хранилище
- Простая разработка и деплой

Микросервисы (5 разработчиков):
- 10+ различных codebases
- Координация между командами
- Каждый разработчик должен знать 3-4 сервиса
- Постоянные проблемы с интеграцией

3. Доменная граница не определена

Без чёткого понимания границ микросервисов получится распределённый монолит:

// Плохо — сервисы слишком связаны
UserService -> OrderService -> PaymentService -> InventoryService
             -> NotificationService -> ReportService

// Каждый вызов = network latency + возможность сбоя

// Хорошо — чёткие границы
Получение профиля пользователя (самостоятельный сервис)
Оформление заказа (самостоятельный сервис)
Обработка платежей (самостоятельный сервис)

4. Высокие требования к консистентности данных

Микросервисы жертвуют ACID свойствами ради масштабируемости:

// Монолит — легко
@Transactional
public void transferMoney(String from, String to, BigDecimal amount) {
    Account sender = accountRepository.findById(from);
    Account receiver = accountRepository.findById(to);
    
    sender.setBalance(sender.getBalance().subtract(amount));
    receiver.setBalance(receiver.getBalance().add(amount));
    
    // Всё откатится если ошибка
}

// Микросервисы — нужна сложная логика Saga
public class TransferSaga {
    // 1. Списываем со счёта 1
    // 2. Добавляем на счёт 2
    // 3. Если ошибка на этапе 2 — откатываем этап 1
    // 4. Обработка конфликтов...
}

5. Недостаточная нагрузка

Микросервисы имеют выше overhead, чем монолит:

Монолит: 
- 1 JVM, 512 MB памяти
- Латенси: 5ms
- CPU: 10%

Микросервисы:
- 5 JVM по 256 MB = 1.2 GB памяти
- Латенси: 50ms (из-за сетевых вызовов)
- CPU: 15% (из-за сериализации/десериализации)

Результат: дороже, медленнее, для той же нагрузки

6. Недостаточная инфраструктура

Микросервисы требуют продвинутого DevOps стека:

✓ Kubernetes или Docker Swarm
✓ Service discovery (Consul, Eureka)
✓ Load balancer
✓ Distributed tracing (Jaeger, Zipkin)
✓ Centralized logging (ELK stack)
✓ Monitoring (Prometheus, Grafana)
✓ CI/CD pipeline для каждого сервиса
✓ Автоматическое масштабирование

Без этого → хаос

7. Слабое понимание требований

Микросервисы требуют стабильного API контракта:

// Если требования меняются каждую неделю
// Постоянно переделываешь API контракты
// Обновляешь версии сервисов
// Синхронизируешь развертывание

// В монолите просто рефакторишь код

8. Высокая зависимость между доменами

// Примеры сильной связанности
// которую сложно разделить:

// Электронная торговля
// - Заказ зависит от каталога (цены, наличие)
// - Каталог зависит от рейтинга (есть ли отзывы)
// - Рейтинг зависит от заказов

// Социальная сеть
// - Лента зависит от подписок
// - Рекомендации зависят от действий друзей
// - Уведомления зависят от всего

// В таких случаях микросервисы добавляют сложность

Рекомендации по выбору

Используй МОНОЛИТ если:
✓ Команда < 10 человек
✓ Бизнес требования не стабилизировались
✓ ACID транзакции критичны
✓ Нет чётких доменных границ
✓ Нагрузка < 1000 RPS
✓ Команда не имеет опыта с микросервисами
✓ Нет продвинутого DevOps

Перейди на МИКРОСЕРВИСЫ когда:
✓ Команда > 10-15 человек
✓ Требования стабилизировались
✓ Есть чёткие доменные границы (DDD)
✓ Разные сервисы нужно масштабировать независимо
✓ Нагрузка > 5000 RPS
✓ Есть зрелый DevOps
✓ Команда имеет опыт

Вывод

Начни с монолита. Переходи на микросервисы только когда боль от монолита станет больше, чем боль от микросервисов.