Shared-Pool Multiplexing

Siloed provisioning wastes capacity by construction: each workload's dedicated storage must be sized for that workload's peak, so every valley — every off-peak hour, every idle weekend — is bought and unused, multiplied by the number of silos. The pattern pools the substrate instead: one shared storage pool under one control plane, serving workload classes with opposite shapes — latency-critical serving with hard peaks, and elastic batch work that can run whenever capacity is free. Provision the pool for the interactive peaks; schedule batch into the valleys; maintain per-tenant isolation as an actively enforced illusion of the control plane rather than a physical fact. Colossus states the doctrine at cluster scale (VM traffic, YouTube serving, and MapReduce sharing one exabyte pool) and repeats it at device scale: buy just enough flash to pull hot-data I/O density per gigabyte into what disks natively provide, spread newly written (statistically hottest) data across all drives, and rebalance data onto larger-capacity drives as it cools — every device class kept doing exactly what it is economical at.

The pattern's price is that isolation becomes a service-level obligation. Physical silos isolate by construction; a shared pool isolates by continuous enforcement — admission, placement, and scheduling must deliver the illusion for every tenant class simultaneously, and a failure of enforcement is a noisy-neighbor incident across workloads that were never supposed to meet. Boundary against load-bearing-cache: that pattern is about a performance layer that has silently become capacity; this one is about deliberately pooling capacity and harvesting its statistical slack.