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
alex (he/him)
alex (he/him)3w ago
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?
elithrar
elithrarOP3w ago
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.
alex (he/him)
alex (he/him)3w ago
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?
elithrar
elithrarOP3w ago
You'd use concurrency controls to limit specific Workflows to a total maximum, once we deliver them.
alex (he/him)
alex (he/him)3w ago
Any workaround which works today?
Unknown User
Unknown User3w ago
Message Not Public
Sign In & Join Server To View
alex (he/him)
alex (he/him)3w ago
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 🤔
Want results from more Discord servers?
Add your server