Приложение падает в день премьеры: как выдержать 500 заявок за 10 минут

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

Почему приложение для медиа и развлечений падает в день премьеры или релиза

Сеть из 12 кинотеатров открывает продажу билетов на новый блокбастер ровно в 9:00. За первые семь минут в приложение прилетает около 500 заказов на места в трёх залах. Каждый запрос сервер обрабатывает синхронно: проверяет свободное место в 1С, ставит бронь, списывает деньги через платёжный шлюз. Но 1С не проектировали под сотни одновременных обращений к одной и той же таблице мест — база начинает блокировать записи, очередь запросов растёт, приложение показывает крутящийся индикатор пять секунд, потом десять, а затем просто рвёт соединение.

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

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

Три технические причины, из-за которых это происходит

• ✓синхронные вызовы к 1С на каждое действие пользователя — выбор места, проверка остатка, подтверждение оплаты идут отдельными запросами к одной и той же базе;
• ✓отсутствие кеша каталога сеансов, залов и билетов — приложение каждый раз запрашивает актуальность у 1С вместо того, чтобы читать из быстрого промежуточного слоя;
• ✓сервер подобран под средний трафик месяца, а не под всплеск в первые минуты продаж, когда нагрузка в десятки раз выше обычной.

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

Как исправить сбой приложения, если он уже случился

Если приложение уже легло у пользователей, первая задача — не чинить архитектуру на лету, а остановить дальнейшие потери. Порядок действий в первые часы после сбоя обычно такой:

• ✓включить очередь на сервере, чтобы заказы принимались последовательно, а не валили базу параллельными запросами;
• ✓временно перевести каталог сеансов или контента в режим «только чтение» из кеша, отключив прямые обращения к 1С на каждый просмотр;
• ✓заблокировать повторную отправку одной и той же заявки с клиента, чтобы не плодить дубли броней и списаний;
• ✓нарастить ресурсы сервера на время пиковых продаж — вертикально или добавлением дополнительных обработчиков;
• ✓подключить к разбору специалиста, который администрирует 1С, — временное ускорение сериализации операций на стороне базы часто снимает затор быстрее, чем правки в мобильном клиенте;
• ✓отправить пользователям, у которых списались деньги без брони, push или письмо с объяснением и сроком возврата — это снимает часть негатива быстрее, чем молчание.

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

Что делать, если ошибка повторяется после каждого обновления

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

Разорвать этот цикл помогает три шага. Первый — нагрузочный тест с объёмом данных и всплеском запросов, близким к реальному пиковому дню, а не к среднему трафику недели. Второй — вынести синхронизацию заказов и остатков с 1С в асинхронный обмен: приложение резервирует место сразу, а подтверждение в учётной системе происходит в фоне, без ожидания ответа от базы на экране пользователя. Как строить такой обмен, разобрано в статье про интеграцию приложения с 1С — там же описано, какие данные логично передавать в реальном времени, а какие достаточно синхронизировать раз в несколько минут.

Третий шаг — мониторинг с алертами по времени ответа API и очереди в 1С, а не только по факту падения сервера. Требования к серверу, на котором крутится сама 1С, для стабильной работы с мобильным приложением описаны в системных требованиях 1С — на практике конфигурация, которая устраивала офис на 15 бухгалтеров, обычно не тянет ещё и поток заказов из приложения на тысячи пользователей.

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

Как предотвратить сбои в высоконагруженных сценариях: стриминг, билеты, лояльность

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

Разделяйте раздачу медиа и транзакции

Видео и аудио отдаются через CDN и не касаются той же базы, что обрабатывает оплату и бронь. Когда тысяча человек одновременно смотрят премьеру сериала, это не должно создавать нагрузку на сервер, который параллельно принимает заказы на билеты в другом разделе того же приложения.

Кешируйте каталог на устройстве, а не только на сервере

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

Стройте каталог и заказы поверх готовой архитектуры, а не шаблонного конструктора

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

Для внутренних сценариев — лояльность, доступ сотрудников к контенту — используйте корпоративный контур

Если приложение раздаёт бонусы партнёрам кинотеатра, предоставляет доступ к внутренней медиатеке для сотрудников или синхронизирует остатки мерча между точками продаж, для таких сценариев подходит отдельный класс решений — B2B-приложение с 1С, где транзакционная логика изначально рассчитана на массовую, но предсказуемую нагрузку, а не на непредсказуемый всплеск от внешних пользователей.

Отдельно закройте вопрос персональных данных

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

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

Стоимость зависит не от количества экранов, а от того, сколько сценариев требуют мгновенной синхронизации с 1С и насколько резкими будут всплески трафика.

Разработка мобильного приложения с каталогом, оплатой, синхронизацией с 1С и админ-панелью начинается от 500 000 рублей — итоговая сумма считается после короткого технического аудита текущей нагрузки и интеграций. Цена растёт вместе с числом интеграций — отдельно билеты, отдельно программа лояльности, отдельно push-уведомления — и с требованиями к платформам: параллельная разработка под iOS и Android обходится дороже, чем одна платформа с последующим переносом. Эти параметры лучше закладывать в техническое задание на старте, а не выяснять после первого счёта от подрядчика. После запуска поддержка кода и реакция на инциденты в пиковые даты обычно тарифицируется почасово, от 3800 рублей в час, — актуальные условия и пакеты собраны в разделе цены и тарифы.

❓ Частые вопросы

Можно ли доработать существующее приложение, чтобы оно не падало при пиковой нагрузке, или нужно переписывать с нуля?

В большинстве случаев достаточно доработки: вынести синхронизацию с 1С в очередь, добавить кеш каталога и настроить масштабирование сервера на пиковые даты продаж или релизов. Полная переработка нужна, только если архитектура изначально построена на прямых синхронных вызовах к базе на каждое действие пользователя без единого промежуточного слоя.

Сколько времени занимает исправление архитектуры под пиковые нагрузки?

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

Нужно ли переносить 1С на отдельный сервер, если приложение работает с ней напрямую?

Если 1С одновременно обслуживает офис и мобильное приложение, при всплеске заказов из приложения тормозит вся компания, включая бухгалтерию и склад. Вынос базы под интеграцию на отдельный сервер снимает эту зависимость и не даёт сбоям в приложении отражаться на остальной работе организации.

Как понять, что приложению для билетов или стриминга не хватит текущего сервера в следующий сезон?

Ориентир — нагрузочный тест с объёмом заказов, близким к пиковому дню, а не к среднему трафику месяца: разовый всплеск за первые минуты продаж или после массовой push-рассылки. Если в тесте база 1С или API отвечают дольше двух-трёх секунд, текущей конфигурации не хватит на реальный релиз.

Что входит в стоимость разработки приложения для медиа и развлечений от 500 000 рублей?

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