Весна 2020 года сместила спрос в онлайн быстрее любых прогнозов. Магазины, которые раньше относились к интернет-каналу как к витрине, столкнулись с реальностью: трафик вырос в разы, а монолитная платформа на одном арендованном сервере легла под нагрузкой. Параллельно Wildberries, Ozon и Яндекс.Маркет превратились из дополнительного канала сбыта в основной и потребовали интеграций, к которым большинство учётных систем не готовы. Рост продаж сегодня упирается не в маркетинг, а в архитектуру. Разберём, как её строить.

Разделяйте витрину, ядро и интеграции

Главная ошибка – держать каталог, корзину, оформление заказа, складской учёт и обмен с маркетплейсами в одном приложении и одной базе. Любой всплеск трафика на витрине тормозит обработку заказов, а сбой синхронизации с Ozon роняет сайт. Разделите систему на независимые сервисы: каталог с поиском, заказы, платежи, склад, шлюз интеграций. Каждый масштабируется отдельно – витрину под пиковую посещаемость, обработку заказов под фактический поток покупок.

Такой подход мы подробно описывали в материале об экосистемном подходе к корпоративным системам: сервисы общаются через явные контракты и очереди, а не лезут напрямую в чужую базу. Для e-commerce это означает, что прайс-лист, остатки и статусы заказов передаются через брокер сообщений. Если маркетплейс недоступен, сообщения копятся в очереди и уходят при восстановлении связи – продажи не останавливаются.

Готовьтесь к пикам заранее

Распродажи, сезонный спрос и рекламные кампании дают нагрузку, которая отличается от обычной в десятки раз. Закладывать постоянные мощности под пик – дорого и бессмысленно. Контейнеризация и оркестрация решают задачу: витрина и сервис заказов разворачиваются в нескольких репликах, а число реплик растёт автоматически вслед за нагрузкой. Как это выглядит в эксплуатации, мы показывали в разборе Kubernetes в продакшене – там же про health-чеки и плавные обновления без простоя.

Отдельно – про данные. Каталог читается на порядок чаще, чем меняется, поэтому его выносят в кеш и поисковый индекс. Заказы и платежи, наоборот, требуют строгой согласованности и транзакций. Не пытайтесь обслужить оба сценария одной СУБД в одном режиме: разделите потоки чтения и записи, вынесите тяжёлые отчёты на реплику.

Защита платежей и данных покупателей

Чем выше оборот, тем привлекательнее магазин для атак. Платёжные данные нельзя хранить у себя – работайте через сертифицированные PCI DSS платёжные шлюзы, на своей стороне держите только токены. Персональные данные покупателей подпадают под 152-ФЗ: размещение в России, согласия, журналирование доступа. Административные интерфейсы – панель управления заказами, выгрузки, доступ интеграторов – закрывайте по принципам, описанным в статье о безопасном удалённом доступе: отдельный контур, многофакторная аутентификация, журналирование действий.

Для проектов в госсекторе и крупном B2B добавляется ещё один слой – интеграция с внутренними учётными системами, ЭДО и контролем закупок. Здесь шлюз интеграций становится центральным узлом, и проектировать его нужно с тем же запасом прочности, что и приём заказов.

Вывод

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