porahuy.group Docs Hub
Оберіть продукт, щоб відкрити відповідну документацію.
Telegram client runtime
Поточний Telegram backend працює тільки через TDLib. Команди з WebSocket або GraphQL не виконуються напряму в web-процесі: вони публікуються в NATS JetStream, маршрутизуються за shard і виконуються відповідним owner worker.
У production запущено 8 owner services, кожен відповідає за свій range із 256 shards. etcd зберігає leases та epoch, NATS доставляє owner commands, а TDLib sessions відкриваються тільки після proxy enforcement.
Owners and shards
8 owners ділять shards по 32. Кожен owner читає тільки свої NATS subjects і тримає тільки свої etcd leases.
Owner commands
Зовнішні payload-и не змінюються. Всередині система додає routing metadata, expected owner epoch і доставляє команду через JetStream.
Live delivery
TDLib updates, command responses і media_ready пишуться в TG_EVT та targeted Core NATS subjects rt.*. WS підписується тільки на відкриті акаунти.
TDLib sessions
Main session обробляє dialogs/messages/profile commands. Media session використовується для media flow і не ламає існуючу media-архітектуру.
Proxy enforcement
Будь-яка взаємодія з Telegram без proxy блокується. Main, media та auth sessions отримують backend-owned proxy перед створенням TDLib client.
Media and CDN
Telegram file operations ідуть через TDLib proxy. CDN/S3 upload, lookup і download виконуються напряму без Telegram proxy.
Failure recovery
Owner retry-ить etcd attach, re-acquire після TTL expiry, чистить stale NATS consumers і fail-fast блокує Telegram-запити без proxy.
TDLib only
8 shard owners
etcd leases
NATS JetStream
main + media sessions
proxy required for Telegram
direct CDN/S3