CABUS — это система автоматизации для ресторанов. Одна из её ключевых функций — приложение для кухни: повара видят заказы с кассы на планшетах и смартфонах вместо дорогих стационарных дисплеев.

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

В итоге мы приняли решение полностью переписать сетевой слой на HTTP — и ниже расскажем, почему пришлось отказаться от «модного» протокола и как мы к этому пришли.

Предыстория

Android-приложение для кухни, которое разработал CABUS, в нескольких заведениях функционировало штатно.

Когда начали подключать новые рестораны — система дала сбой.

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

КОД9 пригласили для диагностики и стабилизации приложения.

С чего мы начали

Первым делом — аудит кода.

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

Стали копать глубже. Грешили на сетевое оборудование ресторанов: ставили снифферы, анализировали трафик, тестировали бэкенд. Безрезультатно.

В итоге мы поняли, что проблема не в коде и не в роутерах. Проблема в самом выборе протокола. Сетевое оборудование ресторанов агрессивно обрывало неактивные TCP-соединения примерно через 60 секунд простоя. Сервер не успевал отправить keep-alive, роутер молча убивал сессию, а клиентское приложение не получало уведомления о разрыве.

И WebSocket превращался в фантомное соединение: интерфейс показывал, что приложение онлайн, но данные уже никуда не уходили.

Нам пришлось признать: архитектура, которую мы унаследовали, не подходит под реальные условия заказчика. И это было не «баг в коде», а фундаментальное несоответствие технологии инфраструктуре.

Почему WebSocket не подошёл

У WebSocket одно постоянное соединение. При стабильной сети это даёт преимущество: данные ходят мгновенно. Но в ресторанах Wi-Fi — вещь непредсказуемая: роутеры разных моделей, загруженные сети, десятки подключённых устройств.

При обрыве соединения WebSocket начинает восстановление. Пока он переподключается, заказы не проходят, статусы зависают. При частых сбоях приложение уходило в бесконечный цикл переподключений.

Для бизнеса это означало одно: каждый новый ресторан = новые жалобы и обращения в поддержку. Масштабировать систему в таком виде было нельзя.

Решение

Мы предложили заказчику перейти с WebSocket на HTTP.

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

Мы прикинули варианты: можно было пытаться «лечить» текущий WebSocket: внедрить heartbeat-пакеты и локальную очередь событий на клиенте, чтобы компенсировать обрывы. Или перейти на специализированные протоколы вроде MQTT или Server-Sent Events. Но в итоге решили вернуться к классическому HTTP.

И вот почему:

• каждый запрос — это отдельное короткое TCP-соединение. Отправил запрос, получил ответ, закрыл. Нет долгоживущей сессии, которая может незаметно умереть.
• инфраструктура ресторанов уже заточена под HTTP. Прокси, фаерволы, балансировщики корректно обрабатывают короткие stateless-сессии и не обрывают их по таймауту, как это происходит с долгими WebSocket-соединениями.
• это проще поддерживать: команду не нужно учить новому стеку, а отладка занимает минуты, а не часы.

Мы честно сказали заказчику: да, мы теряем мгновенную доставку. Но для кухни это не критично — повару важнее, чтобы заказ вообще дошёл и не потерялся, а не то, чтобы он дошёл на 200 мс быстрее.

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

Как мы это внедряли

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

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

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

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

Редизайн без изменения UX

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

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

Итог

Жалоб больше нет, приложение работает стабильно. Обращения в поддержку по сетевым проблемам исчезли полностью.

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

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

Параллельно с техдолгом мы провели редизайн — теперь приложение воспринимается как продукт, а не как MVP.

КОД9 сопровождал проект на всех этапах: от диагностики до перехода на HTTP, редизайна и запуска. Сейчас поддерживаем продукт — тестируем обновления, помогаем с развитием. Подробности — в кейсе на сайте.