Что нужно резервировать в ботовой системе

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

Разберём по порядку.

1️⃣ Сервер и зоны размещения

Для критичного бота желательно иметь:

• 🔹несколько экземпляров приложения;
• 🔹резервную зону доступности;
• 🔹отдельную площадку или облачного провайдера;
• 🔹независимые сетевые маршруты;
• 🔹заранее подготовленную конфигурацию для запуска.

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

2️⃣ База данных

В базе находятся не только пользователи. Там могут быть:

• 🔹заявки;
• 🔹заказы;
• 🔹статусы оплат;
• 🔹история отправок;
• 🔹настройки маршрутизации;
• 🔹шаблоны сообщений;
• 🔹связи между Telegram, MAX и VK;
• 🔹согласия пользователя на получение сообщений.

Для защиты данных нужны два разных механизма. Репликация - резервная база постоянно получает изменения из основной. Это позволяет быстро переключиться. Бэкап - сохранённая копия базы на определённый момент времени. Она помогает восстановиться после удаления данных, ошибки в коде или повреждения базы. Репликация ускоряет переключение, но может скопировать ошибку. Например, если приложение удалило тысячу записей, они могут исчезнуть и на реплике. Поэтому нужны и репликация, и бэкапы. А ещё бэкап необходимо проверять восстановлением. Если копия есть только в панели управления, но из неё нельзя поднять рабочую базу, это не резерв.

3️⃣ Очередь сообщений

Плохой вариант:

Заявка → приложение → API мессенджера

Если API временно не отвечает, запрос зависает или сообщение теряется. Надёжнее:

Заявка → очередь → воркер доставки → Telegram/MAX/VK

Очередь позволяет:

• 🔹не терять сообщения;
• 🔹повторять неудачные отправки;
• 🔹ограничивать скорость запросов;
• 🔹разделять важные и обычные уведомления;
• 🔹временно накапливать сообщения при сбое;
• 🔹отправлять окончательно не доставленные сообщения в DLQ.

DLQ - это очередь сообщений, которые не удалось доставить после всех попыток. Она нужна, чтобы проблема не исчезала бесследно. Для каждого сообщения стоит хранить:

• 🔹получателя;
• 🔹выбранный канал;
• 🔹количество попыток;
• 🔹последнюю ошибку;
• 🔹внешний идентификатор сообщения;
• 🔹текущий статус доставки.

Например:

created
queued
sending
sent
delivered
failed
retry_scheduled
dead_letter

Если мессенджер вернул ошибку, не нужно долбить его запросами каждую секунду. Используется увеличивающаяся задержка между попытками. А если API передал параметр Retry-After, система должна учитывать его.

4️⃣ Переключение по каналам

Представим, что основной канал - MAX, а резервные - Telegram и VK. Система может работать так:

MAX → ошибка → повторная попытка
    ↓
Telegram → ошибка
    ↓
VK

Для неважного маркетингового сообщения можно попробовать позже. А для подтверждения заказа - сразу использовать резервный канал. Ещё один полезный механизм - circuit breaker, или «предохранитель».

Если Telegram начинает массово возвращать ошибки, система временно исключает его из маршрутизации. Новые сообщения идут в другие каналы. Через некоторое время выполняется пробная проверка. Если Telegram восстановился, он постепенно возвращается в работу. Так система не тратит ресурсы на бесконечные попытки отправить сообщения в неисправный API. Но есть ещё одна проблема: пользователи имеют разные идентификаторы в разных мессенджерах. В Telegram это один ID, в MAX - другой, в VK - третий. Поэтому каналы нельзя просто «зеркалить». Нужна единая карточка клиента и понятный процесс связывания аккаунтов: через авторизацию, номер телефона, персональную ссылку или QR-код.

В следующем посте соберём всё в практический план: что внедрить в первую очередь и как понять, действительно ли ваша система готова к аварии.