Environment:

• Local Telegram Bot API
• bot with hundreds of thousands of MAU
• Users constantly send voicemessages, videonote, audiofiles.

Local Bot API Configuration:

telegram-bot-api \
  --http-stat-port=XXXX \
  --verbosity 2 \
  --log XXXX \
  --local \
  --api-id=XXXX \
  --api-hash=XXXX \
  --max-webhook-connections=1000 \
  --dir=XXXX

Issue Description:
We're experiencing response header timeout errors and MTProto -429 errors when making getFile requests at approximately 15-20 RPS. Telegram-bot-api logs show:

MTProto error: -429] Session:2:download#0::Connect::TCP::[149.154.167.222:443] to MEDIA DcId{2}
NetQueryDelayer] Delay: [Query:[id:xxx][tl:xxx]] [timeout:1][total_timeout:1] because of [Error : 500 : Session failed: MTProto error: -429]

Current Setup:

• We have a queue system with workers processing getFile requests
• Workers maintain ~1 second intervals between requests
• At 15+ concurrent workers, we consistently hit rate limits
• Reducing to 12-13 workers helps but creates queue backlog issues due to high user volume

We try routing 50% of getFile requests through proxy - no improvement (suggests token-based limits, not IP-based)

1. Does using Local Bot API change any rate limits for getFile?
2. Are there Local Bot API parameters that could affect download performance?
3. Are there any recommended patterns for high-volume file downloads?
4. Can you confirm whether Telegram's rate limits for getFile requests are token-based rather than IP-based? Our testing shows that routing 50% of requests through a proxy provides no improvement in rate limit handling, which suggests the limits are tied to the bot token itself rather than the source IP address. Is this understanding correct?

We receive 15-20 files per second. Have we reached the architectural limits of a single bot token?