История о том, почему архитектурная «красота» не всегда означает практическую пользу

Всем привет! Хочу поделиться историей своего архитектурного провала. Началось с простой задачи: парсинг 3 ГБ текстовых данных. Звучит как работа для скрипта? Я же решил, что это отличный повод построить «идеальную» систему на микросервисах. Результат: 4 сервиса, 8 ГБ ОЗУ и 15 ГБ на диске для решения элементарной задачи.

Что пошло не так: хронология переусложнения

Вот архитектура, которую я создал:

1. nodehistj-download-service — отдельный сервис для загрузки файлов

2. nodehistj-newest-nodelists — сервис для работы с актуальными данными

3. nodehistj-historic-nodelists — сервис для хранения исторических данных

4. nodehistj-history-diff — сервис для сравнения версий

Каждый сервис — полноценное Spring Boot-приложение со своей базой PostgreSQL. Единой точки входа не было — клиент должен был общаться с каждым API отдельно.

Цена архитектурных решений

Система потребляла неадекватные ресурсы:

• Память: 6-8 ГБ ОЗУ в простое

• Диск: 15+ ГБ вместо исходных 3 ГБ

• Процессор: 4 ядра для фоновых задач

При этом функциональность оставалась базовой: парсинг текстовых файлов и отображение истории изменений.

Почему это стало проблемой

1. Сложность отладки — поиск ошибок в четырёх независимых сервисах

2. Ресурсоёмкость — высокие требования к инфраструктуре

3. Затраты на развитие — даже простые изменения требовали правки в нескольких сервисах

Выводы, которые я сделал

1. Микросервисы ≠ панацея — они решают конкретные проблемы масштабирования

2. Spring Boot добавляет накладные расходы — каждый модуль имеет свою цену

3. Архитектура должна соответствовать задаче — не стоит создавать распределённую систему для локальной проблемы

4. Интеграционная сложность — отсутствие единого API усложняет клиентскую часть

Этот опыт научил меня трезво оценивать необходимость использования сложных архитектурных паттернов. Теперь я начинаю с простых решений и усложняю систему только при появлении реальных потребностей.

А вы сталкивались с подобными ситуациями? Интересно узнать ваши истории про оптимальный выбор архитектуры для разных задач.