THE SITUATION

A platform that only knew how to grow

The data platform had expanded significantly — new workloads, new teams, new data products. But the underlying Kubernetes infrastructure had not kept pace with that growth in the right way. Everything ran on a single shared cluster. A lightweight ETL job sat next to a heavy analytical workload. A low-priority batch process competed with a business-critical pipeline.

When things slowed down or resources ran short, the answer was always to scale up — add more capacity, increase the node count, absorb the problem. The platform had never learned to scale down. Idle resources ran continuously. Infrastructure costs climbed without a corresponding increase in value delivered.

<aside> 💡

One-size-fits-all model All workloads on the same nodes regardless of size, pattern, or criticality.

</aside>

<aside> 💡

Underutilised resources Lightweight workloads consuming far more infrastructure than their actual needs required.

</aside>

<aside> 💡

Workload interference Heavy jobs could destabilise other workloads — no isolation, no priority boundaries.

</aside>

<aside> 💡

No resource governance No quotas, no team-level visibility, no accountability for consumption.

</aside>

WHAT WE DID

Redesign around workload behaviour, not capacity targets

The fix was not adding more capacity. It was understanding the workload patterns that already existed — and building infrastructure around them instead of forcing every workload to compete on the same shared ground.

1. Workload classification — Audited all existing workloads by behaviour, resource consumption pattern, and business criticality before designing any infrastructure changes. Four categories emerged — heavy, light, critical, and batch. Workload analysis | Pattern mapping | Criticality scoring
2. Dedicated node pools — Created separate EKS node pools for each category — eliminating resource contention and ensuring heavy workloads could no longer destabilise critical pipelines. AWS EKS | Node pool segmentation | Workload isolation
3. Intelligent auto-scaling — Configured scale-up and scale-down policies per pool. Batch workloads moved to spot instances. The platform now releases idle capacity rather than holding it. Cluster autoscaler | Spot instances | Scale-down policies
4. Resource governance — Implemented namespace-level resource quotas — giving each team visibility into their consumption and preventing any single team from starving the shared infrastructure. Resource quotas | Namespace controls | Team governance

WHAT CHANGED

A platform the engineering team can actually manage

The reconfiguration delivered immediate operational improvements — and set up the platform to absorb future growth without the same structural problems recurring.

<aside> 💡

Improved utilisation Infrastructure now scales down as well as up. Idle capacity is released rather than left running — cost follows actual usage.

</aside>

<aside> 💡

Workload isolation Heavy workloads can no longer impact critical pipelines. Each pool runs independently with its own resource boundaries.

</aside>