Share a cluster or split it
Separate clusters buy the sum of the teams' peaks; a shared one buys the peak of their sum. For independent, bursty demand the shared buffer shrinks by about √N: 16 teams that would need 320 slots apart need about 200 together. But that dividend is a dividend on independence, and teams are not independent: month-end close, the 09:00 dashboards and the same upstream pipeline all land at once. Should these teams share?
You will end with how capacity is shared across teams, what each team is guaranteed, and what the arrangement costs on ordinary days and at the peak.
Decide
Do the teams peak independently of one another?
If they all peak at month-end or at 09:00, the answer is no.
Why
Correlation goes to 1 exactly at peak, which is when you needed the gain. If all 16 teams peak together at 20 slots, the shared pool needs 320 slots, not 200. The multiplexing discount is real on average and evaporates in the case you sized for.
Does any team need a guaranteed amount it can always get back?
Can capacity be taken back quickly, by preempting borrowers or by keeping tasks short?
Why
A guarantee you cannot take back is not a guarantee. Without preemption, the owner of a floor waits about as long as the borrower's p99 task: a team guaranteed 30 slots, borrowed by tasks with a 55-minute p99, waits up to about 55 minutes.
Where you can land
Separate clusters
Use it when peaks are correlated.
What it costs: the sum of the peaks, and capacity idle on ordinary days. What it buys is the guarantee that no one else's spike is yours. It is a price quote, not an admission of failure: isolation costs the multiplexing gain you forgo, minus the part of that gain that was fictitious because demand is correlated.
One shared pool with fair shares
Use it when peaks are independent and nobody needs a guarantee.
What it costs: with several resources, fairness means an equal share of each team's dominant resource, and that strands capacity a bin-packer would use: in one example 4 GB of 18 stays idle. And the pool is exposed to its noisy neighbours: cache, memory bandwidth and other resources no quota can attribute to a team.
Shared pool with guaranteed floors
Use it when peaks are independent, some teams need a guarantee, and capacity comes back quickly.
Each team gets a floor and may borrow idle capacity above it.
What it costs: preemption destroys the borrower's work, or a maximum task length constrains every job. A guarantee is only as quick as the grain at which resources are handed back.
Split out the teams that need guarantees
Use it when a guarantee is needed and capacity cannot be reclaimed fast.
What it costs: those teams pay their own peak, and the rest still share.
Whichever you land on
Give short queries a lane, not a priority
Priority reorders a queue; it does not move a short query that was admitted behind a long one. Only a reserved lane, preemption, or routing at admission does. A reserved lane costs its idle capacity. When the classifier is unsure, send the query to the short lane: misrouting a long query costs one lane's capacity for one query, misrouting a short one costs its latency.
Know what a quota cannot govern
A quota governs only what can be named and attributed to a team: CPU-seconds, bytes scanned, slots. Over long-running tasks, even a hard quota is enforced only when something is released.