Rukki.pro: backend, Telegram-бот и marketplace-флоу

Rukki.pro - marketplace-экосистема, где backend обслуживал мобильное приложение, web-интерфейс и Telegram-бота. Бот был не второстепенной “уведомлялкой”, а отдельным каналом работы с пользователями: рассылки, подписки на статусы заказов, админские сценарии и платежи.

Проект развивался постепенно: часть логики жила в монолите, часть функциональности нужно было выносить в отдельные сервисы. Поэтому важной задачей было не только добавлять новые endpoint'ы, но и снижать связность между ботом, backend и уведомлениями.

Моя роль

Я работал над backend монолита, backend Telegram-бота и участвовал в Telegram Web App.

В монолите занимался:

• REST API для мобильного приложения, web и Telegram-бота;
• реферальной системой: регистрация по партнерской ссылке и начисления после закрытого заказа;
• поддержкой документации в Swagger и Notion;
• сервисом уведомлений: SMS, email, push, web push и Telegram;
• socket.io сервисом для чатов и уведомлений об изменении статусов заказов;
• заменой HTTP-вызовов к боту на коммуникацию через Redis.

В Telegram-боте:

• строил архитектуру на NestJS и Telegraf;
• логировал действия пользователей в MongoDB;
• разрабатывал панель управления для менеджеров и администраторов;
• делал массовые рассылки о новых заказах;
• реализовывал подписки на обновления статусов заказов;
• занимался рекуррентными платежами и интеграцией с платежным шлюзом Impaya.

В Telegram Web App:

• помогал строить архитектуру по feature-sliced;
• писал хуки для Telegram Web App API: главная кнопка, кнопка назад, vibration feedback и другие сценарии;
• участвовал в авторизации через защищенную передачу Telegram ID на backend бота.

Технический акцент

Один из заметных переходов - отказ от прямого HTTP-взаимодействия с ботом там, где это создавало лишнюю связность. Redis-коммуникация позволила сделать обмен событиями спокойнее: backend мог публиковать изменение, а бот обрабатывать его как отдельный участник системы.

Еще одна важная часть - realtime и уведомления. Marketplace-сценарии завязаны на статусах заказов, поэтому пользователю важно быстро узнать о новом заказе, отклике, изменении статуса или сообщении в чате. Это требовало отдельного socket.io сервиса и аккуратной интеграции с основным backend.

Результат

Проект дал практический опыт работы с продуктовой экосистемой, где один backend обслуживает несколько клиентов и каналов коммуникации. Для меня это был важный шаг от “пишу API” к проектированию связей между web, mobile, bot, уведомлениями, платежами и realtime-сценариями.