Архитектура онлайн-сервиса: пять вопросов, которые избавят от лишних расходов

Обсуждение архитектуры цифрового сервиса на старте в будущем избавит от дорогостоящих «пересборок» и неоправданных расходов на поддержание работы. В этой статье разберем пять важных вопросов к архитектуре онлайн-сервиса и расскажем, как заранее проверить, верно ли на них ответила команда-разработчик.

Обсуждать архитектуру цифровых продуктов на старте — выгодно

Проработка архитектуры цифрового продукта обычно остается технической команде и стартует уже после того, как написано техническое задание. Это происходит потому, что ТЗ пишется на языке бизнеса, понятном заказчику и продакт-менеджеру, а системных архитекторов или ведущих разработчиков нанимают позже.

Но нередко такая архитектура системы, которую не учли на этапе написания ТЗ, а «подогнали» под требования, приводит к неприятным последствиям уже после запуска. Добавление каждой новой функции стоит дороже предыдущей, интеграция требует отдельного бюджета, рост аудитории упирается в пересборку системы: возникает то, что инженеры называют «техническим долгом».

Опасаясь этого, заказчики порой впадают в противоположную крайность — стремятся включить технических специалистов как можно раньше и описать проект во всех возможных подробностях еще до старта разработки. Это ведет к многочасовым обсуждениям с погружением в технические детали и подробнейшим объемным ТЗ, а также стремлению заказчика контролировать все этапы. Но в итоге старт проекта сильно затягивается и задерживается, что может обернуться крупными убытками.

Как обычно, лучший выбор — «золотая середина»: не игнорировать архитектуру проекта на старте, но обсудить только самые важные ее аспекты. По мнению экспертов Uplab, которые уже более 10 лет разрабатывают цифровые сервисы для бизнеса, вот ключевые вопросы:

1. Микросервис или монолит?

2. API-first или Code-first?

3. Что произойдет в случае роста?

4. Для каких частей системы важна устойчивость?

5. Как защитить данные и вовремя заметить сбой?

Микросервис или монолит?

Если сервис спроектирован как единый блок, или монолит, новую функцию нельзя просто добавить. Ее приходится встраивать в общую логику, и разработчики тратят время на проверку соседних разделов, а не на саму задачу. Микросервисная архитектура относится к инструментам, которые позволяют быстро и без лишних затрат вносить изменения: правка в одном модуле не требует перепроверять всю систему.

У микросервисной архитектуры есть цена на старте. Она дороже в разработке, ведь проектирование компонентов и правил их сочетания занимает время. Есть и другие сложности — о них мы подробно рассказывали в отдельной статье блога, посвященной микросервисам.

Подход полностью окупается, если сервис планируется развивать и новые функции будут появляться часто; кроме того, можно быстро запустить минимальную жизнеспособную версию продукта, которая содержит только часть будущих модулей. Если же новые функции будут появляться раз в несколько лет, монолитная архитектура может быть хорошим бюджетным выбором.

Мы использовали микросервисный подход в проекте «Северсталь Стальные Решения»: это позволило реализовать MVP проекта всего за три месяца.

API-first или Code-first?

Интеграции часто становятся источником незапланированных расходов для владельцев продукта. Например, сервис подключают к CRM, затем к коллтрекингу, затем к службе доставки; если каждый раз проектировать с нуля, получим несколько проектов с отдельным сроком и бюджетом. Поэтому в сложных системах с множеством интеграций выгодно изначально выбрать API-first подход.

В таком подходе сначала проектируют и документируют программные интерфейсы, через которые система обменивается данными: это и есть API. Также задаются контракты, то есть описания правил обмена, включающие порты и типы данных. Функции собирают вокруг них, как детали конструктора. Новый сервис подключается к готовому контракту: команда настраивает обмен, а не пишет интеграцию заново.

Для Volta Energy, поставщика оборудования для солнечной энергетики, мы делали интернет-магазин сразу для бизнеса и частных покупателей. Это стало возможным благодаря API.

Систему с самого начала строили как узел интеграций, среди которых 1С (выгрузка на сайт товаров с актуальными характеристиками и ценами), Битрикс24 (прием заявок в CRM), «Деловые линии» (расчет доставки), аналитика Calltouch и сервис рассылок SendSay. Подход окупился: конверсия в заявку на сайте выросла в 3 раза. Подробнее рассказали в кейсе.

API-слой нужен не всегда. По нашему опыту, он выгоднее точечных доработок, если бизнес планирует подключать больше трех внешних систем в год. Когда интеграций 1-3 и новых не предвидится, выгоднее подход Code-first, при котором разработчики сначала пишут бизнес-логику и код на бэкенде, а API появляется позже.

Что произойдет в случае роста?

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

Важно обсудить не только общий объем, но и характер нагрузки: например, распределенная равномерно или «пиками». Это позволит заранее заложить в архитектуру возможности для увеличения мощности отдельных модулей либо всей системы, а не запускать дорогостоящие «пересборки» сервиса, когда придет время для роста.

Чтобы убедиться, что команда разработчика правильно заложила запас на будущий рост, обсудите прогноз развития и задайте вопрос, сколько будет стоить «апгрейд» системы до значений, указанных в плане. Например, «Мы планируем увеличить число позиций в каталоге до 50 000 в течение следующих трех лет и добавить интеграцию с 1С, что для этого понадобится изменить на сайте?».

Для каких частей системы важна устойчивость?

Часы простоя можно перевести в деньги. По отчету ITIC за 2024 год, у 90% крупных компаний час простоя стоит дороже 300 000 $. В среднем и малом бизнесе цифры другие, поэтому важно взвешивать, что обойдется дешевле: часы простоя или дорогая система защиты от отказов.

При проектировании архитектуры отказоустойчивость зависит от того, насколько правильно разделены части сервиса. Чем лучше они изолированы друг от друга, тем меньше риск, что сбой одного компонента остановит работу всей системы. Делать отказоустойчивым на 100% каждый компонент дорого и чаще всего избыточно. Мы советуем начинать с вопроса, какая часть стоит бизнесу дороже всего в час простоя. Для интернет-магазина это корзина и оплата, для B2B-сервиса обычно личный кабинет с заказами.

Например, на нашем сайте, разработанном для Алюминиевой Ассоциации, публичная часть работает на 1С-Битрикс. Личный кабинет сделан отдельным приложением на Vue.js и обменивается данными через REST API. Слои связаны только этим интерфейсом, поэтому сбой или пик в кабинете не роняет сайт.

Как защитить данные и вовремя заметить сбой?

Ошибка в системах безопасности стоит денег: с 30 мая 2025 года за утечку персональных данных компании грозит штраф от 3 до 15 млн рублей в зависимости от масштаба, при этом за повторную утечку штраф повышается. Не менее важно, как быстро компания узнает об инциденте и примет меры: так, об утечке персональных данных нужно уведомить Роскомнадзор в течение 24 часов, это поможет минимизировать штраф.

На безопасность в первую очередь влияют четыре решения.

• Какие данные хранит сервис и где. Персональные данные клиентов, реквизиты компаний, индивидуальные цены партнеров и история заказов требуют разного уровня защиты. Персональные данные граждан России по закону хранят в базах на территории РФ, и это определяет выбор хостинга и внешних сервисов, которым система передает данные.

• Разграничение прав доступа. Это правила о том, какие данные видят сотрудники, партнеры и клиенты. Ролевую модель проще спроектировать до старта, чем потом добавлять права в каждую функцию. Менеджер по продажам не должен иметь возможности выгрузить всю клиентскую базу, а дилер — видеть цены другого дилера.

• Защита интеграций. Каждое подключение к CRM, 1С или платежной системе открывает еще один вход в систему. Ключи доступа, шифрование при передаче данных и ограничения на то, что получает внешний сервис, закладывают вместе с API.

• Обновления после запуска. В готовых библиотеках и CMS регулярно закрывают уязвимости. Заранее договоритесь, кто и как часто обновляет систему после запуска.

Наблюдаемость — это возможность понять, что происходит внутри системы, не дожидаясь жалоб клиентов. В нее входят журналы событий (логи), метрики и оповещения систем безопасности сайта.

Как и в случае с отказоустойчивостью, уровень защиты и мониторинга соразмеряют с рисками. Каталогу без личных кабинетов не нужна та же защита, что B2B-порталу с персональными ценами и документами. Базовый минимум нужен всем: разграничение прав, шифрование, журнал ключевых действий и мониторинг доступности. Остальное добавляют пропорционально ценности данных.

Чтобы система безопасности была надежной, но при этом не избыточно громоздкой и дорогой, ее тоже стоит заложить на первых этапах проектирования. А для этого заказчику и подрядчику важно обсудить, какие данные будет хранить сервис и кто должен иметь к ним доступ.

Все важные вопросы об архитектуре цифрового сервиса в одной таблице

Каждое из пяти решений проверяется одним прямым вопросом к команде или подрядчику. Задать их стоит до того, как написана первая строчка кода. Если в ответ подрядчик задает встречные вопросы, подобные тем, что мы приводим в таблице, это говорит о его стремлении учесть интересы бизнеса и о том, что диалог идет конструктивно.

Если ваш цифровой сервис пока находится на уровне идеи, эти пять вопросов можно разобрать вместе с нашими аналитиками. Свяжитесь с нами через форму «Обсудить проект»!