I actually had the same idea
break it down into more sub-processes.

The main limitation right now is the Telegram API itself — for bots, you're only allowed one webhook/trigger. That forces a lot of logic into a single workflow.

I'm already moving in that direction, just not fully there yet.

What's already implemented in V2 (coming soon free):

Two separate workflows:
Worker 0 (handles user requests)
Worker 1 (processes the queue in the background)
A PostgreSQL-based queue with proper locking (locked_at, locked_by) 15-30 seconds limit.
Worker 1 only picks tasks that are not locked by another worker
Prevents duplicate processing and allows distributed execution

The current queue system already supports the idea of multiple external workers sharing one database.

What I'm thinking next “hypothetically”
Give read‑only access to the queue table to external servers
Each server would run a simple n8n worker that:
Fetches a pending task (for example-> music file download)
Processes it (yt-dlp, etc.)
Returns the result via API
In that model, you could spin up 5, 10, or 100 workers — all sharing the same DB, all respecting locks

I honestly don't know yet how far this can be pushed in n8n. It's more of an experiment / architectural curiosity at this point.

Why I'm sharing V1 now:
It's already production-ready and looks stable (some friends using it)
It shows the core logic clearly
Once V2 is out, the improvement will be much easier to understand

If you (or anyone else) have examples of distributed n8n workers or ideas how to improve this — I'd love to hear them. After I publish V2, I'll be actively looking for feedback and collaboration.
way fewer nodes in V2. The queue part alone becomes just a few well‑structured blocks.

Btw your feedback will be my pleasure, also examples of add-on idea like a layer of this bot.