The author defined fair in a pretty industry standard way:
> One user should not be able to block another's work.
A multi-tenant architecture implies over committing resources to achieve better economics. Once upon a time, decades ago, when computers were so expense that companies payed for batch processing instead of owning their own, FIFO was acceptable. (And for a tiny part of the market it still is.) But ever since the rise of time-sharing operating systems, users have come to expect short delays for small tasks. If you let one customer monopolize your capacity because they submitted a mountain of work before a second customer submits a handful, you probably won't have the second customer much longer.
Fair means that we should be giving users roughly the same capacity, or at least roughly the same chances to be worked on.
In the case of this queue, where each letter represents a user:
[A, Bx10000, C, D, E]
We're being unfair to C, D, and E. Realistically, while working on B's jobs we should have some mechanism to know that latency for C, D, and E are increasing and that we can start assigning them to workers.
Without that, latency for any step function you run is highly variable and impacted by other users. With multi-tenant fairness, latency is purely driven by how well we auto-scale and your own concurrency capacity.
The post here is about multi-tenant fairness in particular, so the intent is that fairness is viewed from a multi-tenant / PaaS lense.
> or at least roughly the same chances to be worked on.
Says who? What if B pays 10000x what ACDE do combined? What if B pays for that capacity?
What if B was silent for the 10000 seconds prior? And is now bursting their load just like ACDE do at other times?
There is no objective fair.
Perhaps the only objectively unfair I could think of is if you paid for a service and it's not rendered, at all, ever. That's probably unfair. But everything else is a grey spectrum in between and depends on the agreed upon properties.
> What if B pays 10000x what ACDE do combined? What if B pays for that capacity?
If B's load is consistently that high compared to the others then presumably the system has enough total capacity that those requests don't impact the latency for everyone else. If B pays for dedicated capacity they should ideally get their own queue.
> What if B was silent for the 10000 seconds prior?
Then B should smooth out their load better.
In this extreme an example, not much is lost for B by prioritizing C, D, E first sometimes anyways.
There might not be one single definition of fairness, but preventing one noisy user from impacting other users is a pretty common way to approach it.
