A commerce platform runs many teams' services on Kubernetes and must survive flash-sale traffic without one team's workload harming another. What cluster and tenancy design should it use?

Why a single large cluster fails

The control plane is shared, and that is the part people underestimate. A misbehaving controller, a runaway number of objects, or a webhook that becomes slow degrades scheduling and API responsiveness for every workload in the cluster. Namespaces isolate naming and policy; they do not isolate the control plane.

Node-level contention is the second problem. Pods without resource requests are scheduled as though they need nothing and then compete for CPU and memory with everything co-located. During a flash sale, a batch job on the same node as a checkout service can degrade checkout, and nothing in the configuration said that was possible.

The third is blast radius during upgrades. A cluster upgrade is an event, and one cluster means one event affecting everything.

Why one cluster per service fails

Operational cost per cluster is roughly constant and substantial: control plane, monitoring, policy, networking, upgrades, certificates. Hundreds of clusters means the platform team's work scales with service count, which is precisely the outcome a platform exists to prevent.

The design that works

Clusters as cells, sized to a blast radius you can accept. Several clusters per region, each running many teams' workloads, with traffic distributable across them. Losing one cell degrades a fraction of capacity rather than all of it, and upgrades roll cell by cell with real traffic validating each step.

Requests and limits mandatory on every workload, enforced by admission policy rather than by convention. A pod with no request is a pod the scheduler cannot reason about, and it is the root of most noisy-neighbour incidents.

Per-namespace resource quotas capping what a team can consume in aggregate, so one team cannot occupy a cell.

Priority classes with preemption, so during a surge, critical workloads can evict batch and best-effort ones. This is the mechanism that makes flash-sale survival automatic rather than manual.

Node pools by workload class, keeping latency-sensitive services off nodes running bursty batch work. This is bulkheading at the infrastructure layer, and it is more reliable than tuning.

Pod disruption budgets so that voluntary disruptions — upgrades, node drains, rebalancing — cannot take a service below its minimum availability.

The flash-sale specific addition

Pre-scale, do not autoscale. Autoscaling responds in minutes; a flash sale arrives in seconds. The cluster must have capacity in place before the event, with autoscaling as a background correction rather than as the primary mechanism. This usually means scheduled scaling tied to the event calendar, and it means accepting idle capacity as the price of readiness.

The honest caveat

For a small organisation, all of this is over-engineering. A single cluster with sensible limits is appropriate for a long time. The cell design earns its cost when the number of teams makes coordination expensive and when a single failure domain becomes an unacceptable business risk — which is a specific, recognisable moment rather than a general principle.