У компаний, где уже есть сайт, CRM, 1С, склад, платежи и BI, затраты на доработки часто начинают расти быстрее, чем эффект от самих изменений. Я вижу это регулярно: новая акция или новый канал продаж цепляет 4-5 систем, и задача, которую бизнес оценивал в неделю, растягивается на 3 недели.
У нас был проект для оптовой компании, где клиент хотел «нормальную платформу». По факту платформа была уже шестой, а сбои возникали по другой причине: никто не зафиксировал, где живет правда по заказу, цене и остатку. Архитектура обычно падает не на 10 000 заказов в день, а на обычной доработке, когда любое изменение затрагивает слишком много контуров.
Проблемы начинаются раньше, чем выбирают Laravel или Java
Спор о Laravel 11, Node.js 20 + NestJS или Java обычно начинается слишком рано. Сначала нужно понять, кто создает заказ, кто меняет его статус, где считается цена и какая система главная по клиенту, остатку и документам. Если этого нет, стек уже мало что меняет.
На B2B-портале старт почти всегда выглядит скромно: каталог, корзина, оформление заказа. Через 4 месяца приходят персональные цены, лимиты, частичные отгрузки, права по филиалам, статусы оплат из ERP. Один раз мы сами недооценили этот рост и потом переделывали структуру заказа и права доступа почти 6 недель.
Я предпочитаю начинать с двух вещей: C4 System Context для бизнеса и C4 Container для команды. Первая схема показывает, какие системы вообще участвуют. Вторая - где будут API, очереди, кэш, фоновые процессы и слабые места.
С чего начинать?
Со схемы процессов и master-данных. Разговор о монолите и микросервисах без этого обычно уходит в пустоту.
Интеграция ломается там, где у систем разные смыслы
Фраза «подключить сайт к 1С» ничего не описывает. Рабочее требование звучит иначе: остатки обновлять раз в 5 минут, цены передавать по событию изменения, заказы отправлять в реальном времени, при ошибке делать повторную отправку до 3 попыток.
На одном проекте заказы уходили с сайта в amoCRM, потом в 1С, а остатки приезжали отдельным обменом со склада. Формально интеграция существовала. На практике менеджеры каждый день вручную уточняли наличие и цену, потому что «клиент» в CRM, ERP и на сайте означал три разных объекта.
После того как мы выбрали master-системы и описали потоки данных, ручных уточнений стало заметно меньше.
До
- изменение цены проходило через 3 системы вручную
- менеджеры правили заказы после обмена почти каждый день
- новый канал продаж оценивался как отдельный мини-проект
После
- ручные уточнения упали на 37% за 6 недель
- заказ передавался автоматически с контролем дублей
- подключение нового канала перестало затрагивать весь контур сразу
Хорошая интеграция - это понятный маршрут данных с заранее описанными исключениями.
Простая архитектура часто дает бизнесу больше пользы
Когда команда состоит из 5-7 человек, релизы идут централизованно, а домены еще не отделились организационно, микросервисы чаще увеличивают стоимость разработки и эксплуатации в 1,5-3 раза. На презентации это выглядит солидно. В ежедневной работе это означает больше DevOps, больше координации и больше точек отказа.
Для таких проектов мы обычно берем модульный монолит: Laravel 11 или Node.js 20 + NestJS, PostgreSQL 16, Redis 7. Внутри - четкие домены: каталог, цены, заказы, пользователи, документы. Так систему проще тестировать, выпускать и развивать, а вынести отдельный сервис можно позже, когда модуль действительно вырос.
| Подход | Запуск | Цена изменений | DevOps |
|---|---|---|---|
| Модульный монолит | 6-10 недель | низкая | базовый |
| Микросервисы | 12-20 недель | средняя или высокая | высокий |
| Event-driven | 10-18 недель | зависит от зрелости | высокий |
В прошлом году мы даже откатывали один проект обратно - от ранних микросервисов к модульному монолиту. Эксплуатационные расходы снизились примерно на 28%, а релизы пошли быстрее, потому что исчезла лишняя координация между сервисами.
Архитектуру стоит строить от точек отказа
Бизнесу важен простой вопрос: что будет, если ERP или платежный шлюз недоступны 20 минут. Если ответ сводится к тому, что все встанет, проблема уже есть, просто ее еще не видно в смете.
На проекте для оптового кабинета ERP по вечерам регулярно уходила в регламентные операции. Раньше заказ в такие окна терялся, менеджер заводил его вручную, а клиент видел разные статусы в кабинете и по телефону. Мы поставили RabbitMQ 3.13, добавили retry, idempotency key и журнал событий. Через месяц потерянные заказы почти исчезли.
Минимальный набор, который я бы не пропускал, если у вас уже 5-7 систем:
- очередь сообщений - RabbitMQ, Kafka или NATS
- контракты API в OpenAPI 3.1 и событий в AsyncAPI
- карта интеграций и ADR по спорным решениям
- наблюдаемость через OpenTelemetry, Prometheus и Grafana
Схема бесполезна, если у изменений нет правил
Я видел хорошие архитектурные схемы, которые за 12-18 месяцев превращались в набор ручных связей. Причина обычно проста: никто не договорился, как версионируются API, кто утверждает изменения и что делать, когда новая бизнес-идея ломает старую модель данных.
Есть один практичный тест, который я советую собственникам и руководителям. Попросите команду нарисовать, что сломается при изменении цены, статуса заказа и карточки клиента. Если на ответ нужен созвон с пятью подрядчиками, кризис уже внутри системы.
Через год рынок будет еще сильнее давить на скорость изменений: новые каналы, B2B-кабинеты, требования к данным, автоматизация продаж. В этот момент выиграют не те, у кого «самая современная» архитектура, а те, у кого цена следующего изменения понятна заранее. Вы сейчас можете быстро сказать, сколько систем затронет новая скидка для ключевых клиентов?
