另外behind scenes，遷移的主要動機其實是：
• Bot HTTP API暴露的資料和接口太少，取得一些user data比較困難，影響BBB的效果。Cloudflare Worker / DO雖然可以outbound TCP（所以可以raw MTProto），但是依然需要一個HTTP請求/cron觸發，且DO的計費完全不適合always on。
• Bot API的抽象為了back compat已經越來越抽象了。
• 業務需求需要大量的scheduling, batching和floodwait-aware backoff，在Cloudflare Worker的抽象里這個只能由Cloudflare Queue/Durable Object提供，但是DO的job scheduling要自己透過alarm來模擬，Queues debug很大坑（畢竟實際上是DO的封裝），而且實測timing很不穩定，粒度也不夠。
• DO必須從worker handoff過去，雖然理論上入口worker很大概率會和DO colo，但是因為DO可用區遠比worker少，而且無法控制Bot HTTP API把webhook打到哪個CF colo，所以實踐里會有一部分webhook在歐洲各地繞一圈回DO的情況，導致延遲不太穩定。