185 lines
8.7 KiB
Markdown
185 lines
8.7 KiB
Markdown
# ADR-004: Стратегия отправки в Telegram (прямой vs агрегатор)
|
||
|
||
**Дата:** 2026-03-20
|
||
**Статус:** Accepted
|
||
**Автор:** Architect Agent (Kin pipeline, BATON-003)
|
||
**Решения:** #1009, #1010, #1011, #1014, #1017, #1020
|
||
|
||
---
|
||
|
||
## Контекст
|
||
|
||
При нажатии кнопки SOS бэкенд должен доставить уведомление в Telegram-группу через Bot API. Вопрос: отправлять каждый сигнал отдельным `sendMessage` (direct) или буферизовать и отправлять пачками (aggregator)?
|
||
|
||
### Rate limits Telegram Bot API
|
||
|
||
| Ограничение | Значение |
|
||
|---|---|
|
||
| Один чат (любой тип) | ~1 msg/сек |
|
||
| Группа | 20 msg/минуту |
|
||
| Глобально | ~30 msg/сек |
|
||
|
||
При превышении: HTTP 429 + `parameters.retry_after`.
|
||
|
||
---
|
||
|
||
## Оценка пиковой нагрузки (#1017)
|
||
|
||
**Параметры:**
|
||
- Зарегистрированных пользователей: 300–400
|
||
- Частота использования: экстренная кнопка — событие редкое
|
||
- Типичная частота: ~1 нажатие/неделю по всей базе
|
||
|
||
**Сценарии:**
|
||
|
||
| Сценарий | Сигналов/мин | Telegram msg/мин | Статус |
|
||
|---|---|---|---|
|
||
| Нормальный (1 пользователь) | 1 | 1 | Лимит: 20/мин ✅ |
|
||
| Групповая тревога (5 человек за минуту) | 5 | 5 | Лимит: 20/мин ✅ |
|
||
| Массовая тревога (20 за минуту) | 20 | 20 | На грани лимита ⚠️ |
|
||
| Абсурдный worst case (все 400) | 400 | 400 | Далеко за лимитом ❌ |
|
||
|
||
**Вывод:** реалистичный пик — 5–10 одновременных сигналов. «Все 400 нажали» — нереалистичный сценарий (разные страны, разные часовые пояса, разные ситуации). Лимит 20 msg/мин покрывает 99.9% случаев.
|
||
|
||
**Решение #1017:** оценки нагрузки в ADR могут быть «drastically wrong» → архитектура должна позволять включить агрегатор без переписывания. Код агрегатора УЖЕ реализован в `telegram.py:51-121` — он просто не активирован.
|
||
|
||
---
|
||
|
||
## Варианты
|
||
|
||
### Вариант A: Прямой sendMessage (1 сигнал = 1 сообщение)
|
||
|
||
```
|
||
[PWA] POST /api/signal
|
||
→ [Backend] save_signal() в SQLite
|
||
→ [Backend] POST api.telegram.org/sendMessage
|
||
→ [Telegram Group]
|
||
```
|
||
|
||
**Плюсы:**
|
||
- Минимальная задержка: сигнал → сообщение < 1 секунды
|
||
- Простейшая логика: нет буфера, нет фоновых задач, нет lock
|
||
- Отладка тривиальна: 1 HTTP вызов, 1 ответ
|
||
- Прозрачность: каждый сигнал виден отдельно в Telegram
|
||
|
||
**Минусы:**
|
||
- При 20+ сигналов/мин → 429 от Telegram → потеря или задержка сообщений
|
||
- Каждый сигнал = отдельное уведомление в группе (шум при массовом событии)
|
||
|
||
### Вариант B: Агрегатор (буфер 10 секунд → batch message)
|
||
|
||
```
|
||
[PWA] POST /api/signal
|
||
→ [Backend] add_signal() в in-memory buffer
|
||
→ [Background task: 10 sec flush loop]
|
||
→ [Backend] POST sendMessage (пакетное сообщение)
|
||
```
|
||
|
||
**Плюсы:**
|
||
- Гарантированное соблюдение rate limits: 6 msg/мин max (1 каждые 10 сек)
|
||
- Компактные сообщения: "🚨 3 сигнала [12:05:00–12:05:08]" вместо 3 отдельных
|
||
- Масштабируется до 1000+ сигналов/мин
|
||
|
||
**Минусы:**
|
||
- Задержка: до 10 секунд между сигналом и сообщением
|
||
- Сложность: asyncio.Lock, background task, graceful shutdown, buffer management
|
||
- In-memory буфер: при crash uvicorn — сигналы в буфере потеряны (SQLite сохраняет, но Telegram не получит)
|
||
- Один uvicorn worker обязателен (буфер в памяти, не shared)
|
||
|
||
### Вариант C: Внешняя очередь (Redis/RabbitMQ)
|
||
|
||
**Плюсы:**
|
||
- Масштабируется горизонтально
|
||
- Буфер переживёт перезапуск процесса
|
||
|
||
**Минусы:**
|
||
- Дополнительная зависимость (Redis) для 1 нажатия/неделю
|
||
- Deployment complexity растёт кратно
|
||
- Абсурдный overkill для 300-400 пользователей
|
||
|
||
---
|
||
|
||
## Решение
|
||
|
||
**Выбран Вариант A: Прямой sendMessage для v1**
|
||
|
||
Агрегатор (Вариант B) оставлен в коде (`telegram.py:SignalAggregator`) но НЕ активирован. При росте нагрузки — включается изменением 2 строк в `main.py`.
|
||
|
||
---
|
||
|
||
## Обоснование
|
||
|
||
1. **#1020: агрегатор нужен только при 20+ одновременных сигналов/мин.** Для 300–400 пользователей это нереалистичный сценарий. Агрегатор — premature optimization.
|
||
|
||
2. **Задержка неприемлема для экстренного приложения.** 10-секундный буфер = 10 секунд ожидания, пока спасатель увидит сигнал. При прямой отправке — < 1 секунды.
|
||
|
||
3. **Код агрегатора уже написан.** `telegram.py:51-121` содержит полный `SignalAggregator` с lock, flush, rate limiting. Включение в v2:
|
||
```python
|
||
# main.py lifespan: раскомментировать 2 строки
|
||
aggregator = SignalAggregator(interval=10)
|
||
asyncio.create_task(aggregator.run())
|
||
```
|
||
|
||
4. **#1017 учтён:** если оценка нагрузки окажется «drastically wrong» — переключение на агрегатор не требует переписывания архитектуры.
|
||
|
||
---
|
||
|
||
## Безопасность Telegram-интеграции
|
||
|
||
### Webhook secret validation (#1010)
|
||
|
||
Каждый входящий запрос на `POST /api/webhook/telegram` ОБЯЗАН содержать заголовок:
|
||
```
|
||
X-Telegram-Bot-Api-Secret-Token: <WEBHOOK_SECRET>
|
||
```
|
||
|
||
Реализовано: `middleware.py:verify_webhook_secret()` — FastAPI dependency, 403 при несовпадении.
|
||
|
||
### HTTPS обязателен (#1011)
|
||
|
||
- Telegram принимает webhook ТОЛЬКО на HTTPS URL
|
||
- Поддерживаемые порты: 443, 80, 88, 8443
|
||
- TLS 1.2 минимум
|
||
- CA-signed сертификат (Let's Encrypt достаточен)
|
||
|
||
### setWebhook vs getUpdates (#1009)
|
||
|
||
Telegram Bot API: `setWebhook` и `getUpdates` взаимоисключающи. Baton использует ТОЛЬКО `setWebhook`. Вызов `getUpdates` автоматически удалит webhook.
|
||
|
||
---
|
||
|
||
## Формат сообщения в Telegram (v1)
|
||
|
||
### Прямая отправка (1 сигнал = 1 сообщение)
|
||
|
||
```
|
||
🚨 SOS от Алиса
|
||
📍 55.7558, 37.6173 (±15м)
|
||
🕐 2026-03-20 14:05:23 UTC
|
||
```
|
||
|
||
Без геолокации:
|
||
```
|
||
🚨 SOS от Алиса
|
||
📍 Геолокация недоступна
|
||
🕐 2026-03-20 14:05:23 UTC
|
||
```
|
||
|
||
Если имя неизвестно (UUID не зарегистрирован):
|
||
```
|
||
🚨 SOS от 550e8400
|
||
📍 Геолокация недоступна
|
||
🕐 2026-03-20 14:05:23 UTC
|
||
```
|
||
|
||
---
|
||
|
||
## Последствия
|
||
|
||
1. **Один uvicorn worker достаточен для v1.** Агрегатор не активен → нет shared state → но для консистентности рекомендуется 1 worker.
|
||
|
||
2. **При 429 от Telegram:** текущий код (`telegram.py:22-25`) обрабатывает retry_after корректно. Сигнал не теряется — он уже в SQLite. Telegram-сообщение задержится на `retry_after` секунд.
|
||
|
||
3. **Переход на v2 (агрегатор):** изменение 3 строк в `main.py` + изменение signal endpoint (вместо прямого sendMessage → `aggregator.add_signal()`). Оценка: 30 минут работы dev-агента.
|
||
|
||
4. **Мониторинг:** логировать 429 ответы от Telegram. Если частота > 1/день — триггер для включения агрегатора.
|