TTVideo
Media download service for Telegram
Send the bot a link and the file arrives in the chat. The heavy lifting runs in queues on separate workers, so one slow request never holds up the rest, and failures are caught by alert rules that live in the repository alongside their tests.
In use
- Telegramdelivers updates to a secret-checked webhook
- Botverifies the secret and queues a job
- Redistwo queues, video and music, plus a cache of sent files
- Workers ×3download and ffmpeg; tracks go through a separate engine, one at a time
- Chatthe finished file is sent to the user
Alongside
- PostgreSQLusers and their settings
- Prometheus and Alertmanagermetrics from every container, rules with tests
- Webhook watchdogchecks the webhook address on a timer
Verifiable decisions
Work is split by cost. Music tracks get their own queue, one at a time per worker, so they never take video slots.
code
Every outbound address is checked at DNS resolution time, on every redirect hop. A string-based address check had already been bypassed with an IPv4-mapped IPv6 address.
tests
A watchdog checks the webhook address on a timer and raises an alert if it changes. It exists because of a real webhook hijacking incident.
incident
Alert rules are kept in the repository and pass promtool tests before they ship.
tests
In detail
Architecture
The bot receives the Telegram webhook and checks the secret header. Without a secret the configuration refuses to start, because otherwise webhook requests would not be verified at all. Downloading and ffmpeg run on three worker replicas, and every container exposes its own metrics registry.
Queues split by cost
Video and music go into different queues. A track costs an order of magnitude more than a video: the engine searches several sources and checks candidates first. In a shared queue a batch of tracks would take every slot, so music has its own queue, one job per worker and its own depth limit.
Redis runs without eviction: when it is full it refuses writes, and the queues stop. That is why every queue has retention limits for completed and failed jobs, and the output of external processes is trimmed before it becomes a failure reason.
Outbound requests
Download addresses come from third parties. The address check happens at DNS resolution time and is repeated on every redirect hop: a string-based address check had already been bypassed with an IPv4-mapped IPv6 address. Environment proxies are disabled for these requests, otherwise the proxy would be resolved instead of the target and the check would silently disappear.
When everything looks healthy
Once the bot’s webhook turned out to point at someone else’s address. The containers were healthy while Telegram kept queueing updates. Now a watchdog checks the webhook address and the number of pending updates on a timer, and alerts go out through a separate bot. The watchdog does not reset the webhook itself: that would hide the hijack, and a restart does not fix it.
Alert rules live in the repository and pass promtool tests. Functional rules catch the pattern “there are attempts but no successful downloads” separately for every source platform.