Ideas for noisy-neighbors in multi-tentant systems
It’s account wide (all of your Workflows). We’ll be bringing per-Workflow controls, and the limit on the paid plan will increase as we go.
7 Replies
Great to know. Does that mean if I have thousands of Workflow A queued, and a new instance of Workflow B comes in, it will be blocked until all of Workflow A are processed?
Yes, if you kicked off only instances of A.
There has to be an account-level limit, otherwise folks would just create copies of the same Workflow to get around it.
Makes sense, how would you solve the noisy-neighbor issue for multi-tenant systems. E.g. how would you achieve fairness, so that one user can't block processing for all users?
For either one workflow type or for multiple workflow types.
Situation A) USER A triggering 100 translation workflows, should not block USER B with his payment workflow
Situation B) USER A triggering 100 translation workflows, and USER B triggering 100 translation workflows, should both get fair amount of runs
How would you solve this?
You'd use concurrency controls to limit specific Workflows to a total maximum, once we deliver them.
Any workaround which works today?
Unknown User•4w ago
Message Not Public
Sign In & Join Server To View
I guess someone can build something custom with a "orchestrator" workflow, which handles concurrency and tracks execution stats, and ony invokes other workflows if it makes sense, potentially using Queues and KV to keep track of items to work on, but that does not sound super robust either or a lot of custom logic 🤔