Всем привет! Меня зовут Даня, я студент Центрального Университета и начинающий Fullstack-разработчик (Python/Go/TypeScript).
В мире разработки часто говорят: «Не изобретай велосипед, бери готовые SaaS». Но что делать, когда готовое решение закрывает 80% задач, но ломает оставшиеся 20%? Именно с такой проблемой я столкнулся, когда решил помочь одному ресторану улучшить обработку заказов.
Отказываться от сайта на Тильде нельзя - домен уже прогрет поисковиками и даёт стабильный трафик. Но и мириться с потерей заявок, отсутствием полной аналитики и «чёрным ящиком» в работе менеджеров - тоже не вариант.
Так и родилась идея гибридной системы: клиентский фронт остаётся на конструкторе, а вся бизнес-логика уходит на кастомный бэкенд.
В этой статье я подробно разберу:
Почму стандартных инструментов оказалось недостаточно и как это повлияло на бизнес.
Как спроектировать архитектуру, которая безопасно дружит с конструктором сайтов (вебхуки, API, валидация).
Как реализовать бонусную систему и запись ключевых действий без потери консистентности данных.
Стэк: Python, FastAPI, PostgreSQL, MongoDB, Redis, Next.js, TypeScript
Поехали 👇
Почему стандартных инструментов оказалось недостаточно и как это повлияло на бизнес
Когда я начал погружаться в процессы ресторана, казалось, что проблема решается покупкой готовой CRM или простым обновлением сайта. Но реальность оказалась сложнее.
У заведения уже был работающий сайт на Tilda. Он выполнял главную функцию - приводил трафик. Домен был прогрет, SEO-позиции были неплохие, и владельцы боялись их потерять. Переезд на новую CMS или разработка фронтенда с нуля означали бы месяцы простоя и риск потерять клиентов.
Но при этом внутри бизнес-процессов был хаос. Вот с чем мы столкнулись:
1. Потеря заказов
Заявки с сайта падали просто в Telegram-бот.
Если менеджер был занят, не видел сообщение или забывал подтвердить заказ - клиент уходил к конкурентам.
По предварительной оценке, до 20% заказов терялись на этапе обработки. Это прямые убытки каждый месяц.
2. Отсутствие работы с лояльностью (LTV)
Тильда отлично собирает лиды, но не умеет управлять клиентами после покупки.
Нет истории заказов, нет понимания, кто посто��нник, а кто сделал первый заказ. Невозможно сделать сегментацию и вернуть «уснувших» гостей персональным предложением.
Ресторан живет только за счет нового трафика, что всегда дороже работы с базой.
3. «Чёрный ящик» внутри команды
Самый болезненный пункт для владельца.
Менеджеры могут тихо отменить заказ, не пробить его, изменить сумму или применить скидку «своему». В стандартных формах Тильды нет аудита действий.
Невозможно понять, где реальная ошибка системы, а где человеческий фактор (или злоупотребление).
Почему не взяли готовую CRM (iiko, Resto и др.)?
Рассматривали и этот вариант. Но интеграция готовых облачных CRM с сайтом на конструкторе часто требует дополнительных костылей или платных виджетов, которые не закрывали нашу кастомную логику бонусов. Плюс, хотелось иметь полный контроль над данными и не зависеть от подписки на сервис, который может изменить тарифы.
Мы приняли решение не ломать то, что работает (фронтенд на Тильде), а заменить «мозги» системы.
Tilda остаётся витриной для клиентов.
Кастомная админ становится единым центром правды для заказов, клиентов и аналитики.
Через интерфейс админки менеджеры могут:
Просматривать все заказы в реальном времени.
Менять статусы заказа (Новый → Готовится → Готов).
Просматривать отзывы и метрики (деньги, лояльность).
Управлять бонусами: просматривать, применять к заказу.
Гости могут оставить обратную связь по заказу (только по недавно завершенному).
Это позволило сохранить SEO-трафик и сразу внедрить сложную логику, которую не дают конструкторы. Далее я расскажу, как технически реализовал эту связку.
Как спроектировать архитектуру, которая безопасно дружит с конструктором сайтов
Интеграция кастомного бэкенда с конструктором сайтов - это всегда работа в условиях неполного контроля. Тильда - это «чёрный ящик»: мы не знаем, как именно она отправляет данные, и не можем гарантировать доставку на 100%.
Моя задача была построить систему так, чтобы ни один заказ не потерялся, а данные не были скомпрометированы.
Схема взаимодействия
Я выбрал архитектуру на основе Webhooks. Это стандартный паттерн для таких задач:
Клиент заполняет форму на сайте, заказ идет на сервера Тильды.
Тильда отправляет POST-запрос с данными заказа на мой эндпоинт.
Бэкенд валидирует данные, сохраняет в БД.
Менеджер видит заказ в отдельном интерфейсе, подтверждает его, меняет статусы, применяет бонус (если есть)
Безопасность и доверие
Самый большой риск - кто-то узнает URL вебхука и начнёт слать фейковые заказы. Чтобы этого избежать, я реализовал несколько уровней защиты:
Secret Token. В настройках вебхука Тильды задаётся секретный ключ. Я проверяю его наличие в заголовках запроса. Если ключ не совпадает - сразу 403 Forbidden.
Валидация данных (Pydantic). Я не доверяю входящим данным. Все поля строго типизированы. Если вместо числа в сумме заказа придет строка - система отклонит запрос.
Логирование. Каждый входящий запрос (успешный или нет) пишется в лог. Если что-то пойдёт не так, у меня будет история для отладки.
Идемпотентность (Защита от дублей)
Вебхуки могут приходить дважды. Например, если Тильда не получила ответ 200 OK вовремя, она повторит попытку.
Если просто сохранять заказ, клиент получит два заказа вместо одного. Чтобы этого избежать, я использовал идемпотентность:
У каждого заказа есть уникальный order_id от Тильды.
Перед созданием записи я проверяю: нет ли в базе заказа с таким order_id?
Если есть - возвращаю успех не создаю дубль.
Деплой и инфраструктура
Чтобы всё это работало стабильно, я упаковал приложение в Docker.
Это позволило мне развернуть систему на обычном VPS за 15 минут и быть уверенным, что окружение одинаково на локалке и на продакшене.
Как реализовать бонусную систему и запись ключевых действий без потери консистентности данных
Каждое действие в админке - это запрос к API, который должен быть безопасным и прозрачным.
Проблема консистентности в бонусной системе
С бонусами всё сложнее, чем с заказами. Здесь нельзя допустить ошибку в расчётах. Основные риски:
Гонка данных (Race Condition): Если два менеджера одновременно попытаются списать бонусы одному клиенту, непонятно что произойдет с бонусом.
Рассинхрон: Бонусы списаны, а заказ отменён. Нужно всё откатывать.
Решение: Транзакции базы данных. Любая операция с балансом клиента оборачивается в транзакцию PostgreSQL. Либо всё проходит успешно, либо откатывается полностью.
Прозрачность для бизнеса в виде Changelog
В начале проекта мы решили, что хотим видеть, кто и когда изменил статус заказа, применил бонус. Для этого я реализовал систему аудита (Changelog). В качестве базы данных для changelog я выбрал MongoDB, ведь логи разные, все зависит от того какое действие делает пользователь.
Как это работает:
В базе есть коллекция audit_logs.
Любое критическое изменение (смена статуса, применение бонуса, отмена заказа) триггерит создание документа в эту коллекцию.
В админке есть вкладка «История», где видно всю цепочку событий с таймстемпами и автором действия.
Пример записи в логе:
12.10.2025 14:30 | Менеджер: Анна | Действие: Смена статуса | Было: Новый → Стало: Готовится
12.10.2025 14:35 | Менеджер: Анна | Действие: Применение бонуса | Тип: Чизкейк
Это решило проблему «чёрного ящика». Если заказ пропал или сумма изменилась, мы всегда можем найти причину в логах.
Итоги и планы
Что мы получили в сухом остатке?
Для бизнеса:
Пропали «потерянные» заказы, теперь каждый заказ попадает в систему и получает статус.
Появилась база клиентов и история их покупок - можно делать рассылки и возвращать гостей.
Исчез «черный ящик», владелец видит, кто, когда и зачем изменил заказ.
Меня этот проект научил:
Проектировать гибридную архитектуру (SaaS + Custom Backend).
Обеспечивать консистентность данных через транзакции.
Строить безопасные API с валидацией и идемпотентностью.
Понял, что кастомная разработка имеет смысл, когда бизнес-логика не влезает в готовые шаблоны.
Сейчас я в активном поиске стажировки или работы junior-разработчиком. Если вам нужен человек, который умеет не просто писать код, а решать бизнес-задачи, — я открыт к предложениям.
Контакты и портфолио
Telegram-канал: t.me/danya_commit - пишу про путь в IT, код и инсайты.
GitHub: github.com/nonsess
Портфолио: ddanjil.ru - больше кейсов и информации обо мне.
Спасибо, что дочитали! Если есть вопросы по архитектуре, стеку или интеграции с Тильдой - пишите, обсудим 👇
