Работал с монолитным или микросервисным приложением

Опыт работы с монолитной и микросервисной архитектурой

Я работал с обоими подходами, и у каждого есть своё время и место.

Монолитное приложение

Контекст: Стартап для управления подписками SaaS. Начинали маленькой командой (3 человека).

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

• Простота разработки — всё в одном месте
• Легче отлаживать (одна база кода, одни логи)
• Проще shared logic — нет дублирования
• Транзакции на уровне БД (ACID гарантии)
• Меньше операционных сложностей

Минусы:

• По мере роста становится всё сложнее
• Одна ошибка может упасть всё приложение
• Разные части масштабируются по-разному

Переход на микросервисы

Архитектура:

API Gateway (Node.js)
├── Auth Service (Node.js)
├── Billing Service (Go)
├── Subscription Service (Node.js)
├── Notification Service (Node.js)
├── Reporting Service (Node.js)
└── Integration Service (Node.js)

Shared:
├── PostgreSQL
├── Redis (кэш, очереди)
├── RabbitMQ
└── ELK

Сравнение подходов

Когда выходить из монолита

1. Более 50k строк кода
2. Разные части скейлятся по-разному
3. Разные требования к надёжности
4. Команда больше 5 человек

Рекомендуемый путь

1. Начни с монолита (быстро и просто)
2. При 50k+ LOC → выдели 1-2 критичных сервиса (платежи, auth)
3. При 100k+ LOC → полноценная микросервисная архитектура
4. Используй message queues для асинхронной коммуникации
5. Инвестируй в наблюдаемость сразу

Типичная ошибка: Разбить монолит слишком рано = ненужная сложность. Монолит нормален, пока работает хорошо.

Key lesson: Выбирай архитектуру в зависимости от размера команды и требований, не потому что модно.