Uplab 
Тендеры и лиды
Информация
Нужно ли фиксировать архитектуру цифрового сервиса в ТЗ? Короткий ответ: да, но не углубляясь в детали. Если этого не делать, повышается риск технического долга и дорогих доработок, но слишком подробное обсуждение наверняка затянет старт проекта. Собрали пять вопросов об архитектуре проекта: они закрывают главные вопросы, помогая заказчику и разработчику лучше описать будущий онлайн-сервис.
Цифровой продукт может быть устроен как единая система (монолит) или как набор независимых маленьких программ (микросервисов), общающихся между собой: это закладывается еще на стадии проекта. Подробнее о разнице подходов мы писали в нашем блоге.
Монолитная архитектура дешевле на старте. Единый блок кода, простое развертывание, меньше инфраструктурных расходов. Но с ростом функциональности стоимость доработки нелинейно увеличивается: каждое изменение затрагивает всю систему, и разработчику нужно постоянно проверять, не сломалось ли после обновления что-то другое.
Микросервисный подход снимает эту проблему — правка в одном модуле не влияет на те, с которыми он напрямую не контактирует. Платить за это приходится на этапе проектирования: описание компонентов и правил их взаимодействия занимает больше времени.
В проекте Uplab «Северсталь Стальные Решения» микросервисный подход позволил запустить MVP за три месяца. Благодаря такой архитектуре получилось вести разработку модулей параллельно, что существенно ускорило процесс.
Если сервис планируют активно развивать, и новые функции будут появляться часто, микросервисы окупятся. Если конфигурация сервиса годами не будет меняться, монолит справится и обойдется дешевле.
Интеграции — частый источник незапланированных расходов. Если сервис подключают к CRM, потом к коллтрекингу, затем к службе доставки, каждая интеграция становится отдельным проектом, потому что обмен данными нужно правильно настроить и протестировать.
API-first подход упрощает интеграции. В нём сначала проектируют программные интерфейсы и фиксируют контракты — описания правил обмена данными, включая форматы и типы. Новый сервис подключается к уже готовому контракту, что гораздо быстрее.
Например, при разработке интернет-магазина для Volta Energy мы изначально проектировали систему как узел интеграций: 1С для выгрузки товаров, Битрикс24 для приема заявок, «Деловые линии» для расчета доставки, Calltouch и SendSay для аналитики и рассылок. Это позволило уложиться в сроки разработки, несмотря на множество сложных взаимодействий с другими системами.
API-слой оправдан не всегда. По нашему опыту, он выгоднее, только если бизнес планирует подключать больше трех внешних систем в год. В остальных случаях лучше применять подход Code-first, в котором разработчики сначала пишут логику сервиса на бэкенде. API на такой сервис можно добавить позже, если появится необходимость.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13796 тендеров
проведено за восемь лет работы нашего сайта.
Масштабируемость — важный аспект для обсуждения на старте. Если планируется расширить каталог компании до десятков тысяч позиций и добавить новые регионы присутствия, разработчик должен знать об этом.
Чтобы заложить запас мощности, нужны конкретные цифры: сколько пользователей, товаров, заказов и филиалов планируется через два года. Не менее важен характер нагрузки — равномерная или пиковая. Интернет-магазин с сезонными распродажами и B2B-портал с ежедневной выгрузкой данных требуют разных архитектурных решений.
Пример вопроса, который даст верное направление для обсуждений: «Мы планируем увеличить каталог до 50 000 позиций за три года и добавить интеграцию с 1С — что для этого придется менять?»
Делать отказоустойчивым каждый компонент цифрового сервиса дорого и чаще всего избыточно. По отчету ITIC за 2024 год, у 90% крупных компаний час простоя обходится дороже 300 000 $. В малом и среднем бизнесе цифры скромнее, но принцип тот же: стоимость защиты нужно сравнивать с суммой, потерянной из-за недоступности веб-ресурса.
Начать обсуждение стоит с вопроса: отказ какой части сервиса обходится бизнесу дороже всего? Для интернет-магазина это обычно корзина и оплата. Для B2B-сервиса — личный кабинет с заказами и документами.
На сайте Алюминиевой Ассоциации мы разделили публичную часть на 1С-Битрикс и личный кабинет на Vue.js. Слои связаны только через REST API, поэтому пиковая нагрузка или сбой в кабинете не роняет основной сайт.
С 30 мая 2025 года за утечку персональных данных компании грозит штраф от 3 до 15 млн рублей в зависимости от масштаба. За повторную утечку суммы выше. Об инциденте нужно уведомить Роскомнадзор в течение 24 часов.
Поэтому на этапе проектирования в архитектуру цифрового сервиса нужно заложить несколько аспектов, важных для его защиты и быстрого обнаружения угроз: классификация данных, разграничение прав, защита интеграций и регламент обновлений.
Отдельная задача — наблюдаемость: логи, метрики и автоматические оповещения, которые позволяют узнать о сбое до первого звонка от клиента. Каталогу без личных кабинетов хватит базового мониторинга доступности. B2B-порталу с персональными ценами и документооборотом нужен полноценный стек наблюдения.
Каждое из пяти решений проверяется прямым вопросом к команде разработки. Задать их стоит до написания первой строчки кода.
Почему выбрана именно эта архитектура (монолит / микросервисы) и как она повлияет на стоимость доработок через год?
Как будут подключаться внешние системы — через единый API или точечными интеграциями? Сколько интеграций запланировано?
Какие параметры роста заложены и сколько будет стоить апгрейд до плановых значений?
Какие компоненты защищены от отказа и почему именно они?
Кто отвечает за обновление системы безопасности после запуска и с какой периодичностью мониторят показатели?
Если подрядчик в ответ задает уточняющие вопросы о бизнес-планах и приоритетах, это хороший сигнал: команда проектирует архитектуру от задач бизнеса, а не от привычного стека.
