Pattern · seen in 2 breakdowns across 1 company

Shared-Pool Multiplexing

Giving each workload its own storage means paying for every peak separately, so create one shared storage pool where background work runs whenever the busy workloads are idle.

throughput

The mechanism

At its core: give every workload its own storage and it sits idle whenever it is not busy, which is most of the time. Pool them under one manager so a workload with sharp busy peaks and flexible background jobs share the same capacity, and the background jobs use whatever those peaks leave free.

LIVE ARTIFACTFILL THE IDLE TIMEOPEN FULL SCREEN ↗
THE IDEAGive each workload its own storage and you have to size each one for its peak, so all the time in between - when it is not busy - is capacity you bought and never use. Pooling puts them together: one shared pool, run by one manager, holding a user-facing workload that must be fast and background work that can run anytime. Size the pool for the busy peaks, and the background work uses whatever is left free, so utilization stays high and you buy far less total capacity. It works because the workloads are not all busy at once - but the catch is that keeping them apart is now the manager's constant job, and if that slips, one greedy workload starves the others.
WHAT TO TRYSpread the workloads' busy times apart and watch the pool you need shrink, since they no longer all peak at once. Then watch the background work fill whatever the serving leaves idle.

Every silo is sized for its own peak, so it sits idle the rest of the time - pool them and background work fills the gaps.

Definition

Give each workload its own dedicated storage and you waste capacity by design. Each one has to be sized for its busiest moment, its peak. So every hour it is not busy - nights, weekends, any lull - is capacity you bought and are not using, and you pay that once for every workload.

The pattern creates one shared storage pool instead, run by one manager, holding two kinds of work that are busy at different times. One kind is user-facing and has to be fast; it gets very busy at peak hours and sits nearly idle the rest of the day. The other is background work with no deadline, which can run whenever there is spare room. You size the pool for the busy workload's peaks, and let the background work run in the time it leaves free. Each workload still feels like it has its own space, but that separation is now something the manager keeps up moment to moment, not a physical wall between separate machines.

SILOS, OR ONE POOL
Each workload with its own peak-sized pool sits mostly idle; one shared pool lets background work fill the gaps.
Give each workload its own storage sized for its peak and it sits idle most of the time; pool them and let background work fill that idle time, so far less capacity is bought.

This works because the workloads are not all busy at the same time. So the pool only needs to be big enough for whatever is busy right now, which is far less than adding up every workload's peak. The background work quietly uses whatever is left over.

The price is that the workloads are no longer kept apart by the hardware itself. On separate machines they simply cannot touch each other; in one shared pool, the only thing keeping them apart is the manager, doing its job every moment. When that enforcement slips, one workload eats into another's capacity - a noisy-neighbor incident between workloads that were never meant to touch. This is a different move from a load-bearing cache, where a speed-up layer slowly turned into capacity by accident; here you pool capacity on purpose, to use the spare room no single workload needs all the time.

When it applies

01Your workloads are busy at different times. When user-facing work that must be fast sits next to background work that can wait, and each runs in its own peak-sized silo today, pooling them puts the idle time to use.
02The pool is big enough that peaks average out. With many workloads whose busy times do not line up, the pool can be much smaller than the sum of their peaks. But if you have only a few workloads and they all get busy at once, pooling saves nothing and just makes them fight over the same space.
03You have a manager that can enforce the separation, all the time. Pooling only works if something continuously controls who gets admitted, where their data goes, and how much each can take - the isolation has to be actively delivered, not assumed.

Tradeoffs

Efficiency is bought with coupling: workloads that used to fail independently now share the same pool, and how well the manager enforces the split is the only thing keeping them apart.
Planning capacity gets harder, not easier. Instead of each team sizing its own silo, one pool's size and admission rules have to balance everyone's peaks at once - a central planning job the silos never required.
Mixing fast and cheap storage is a moving target. When you pool a fast, expensive tier with a slow, cheap one, the right ratio depends on how hot the data is - which keeps shifting, so capacity planning becomes an ongoing adjustment rather than a one-time purchase.

The same move, 2 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Google
Google Cloud Blog
2025
Same-company recurrence, one level down the stack: the scaling article's lesson was many workloads multiplexed onto one pool of storage; this post is about the pool itself being two device tiers — a blended SSD and HDD fleet inside one filesystem — with L4 deciding, per category, which tier each file's I/O lands on. Spanner's tiered storage riding cheap HDD and fast SSD in the same filesystem is the pattern surfaced as product. Read the breakdown →
Google
Google Cloud Blog
2021
This pattern comes from the part of the post about disaggregation: instead of siloing storage per workload, one exabyte-scale pool is shared by live serving and batch work, with each workload feeling like it has its own file system. The pool is sized for the interactive peaks, and batch jobs fill the quiet stretches. The same idea runs inside the hardware tiers: buy just enough fast flash storage to take heavy read demand off the disks, spread new hot data across all drives, and move cooling data to larger drives. It was a new pattern for the catalog; no existing one fit. Read the breakdown →

Often used together

Patterns sharing breakdowns with this one — derived from co-occurrence, threshold ≥2 shared.

distributed-metadata-model ×2

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.

Placement precedes the access patternGOOGLE →Single-cluster scaling ceilingGOOGLE →