An internal platform serves many product teams with very different scale and criticality. How should isolation between them be designed?

The isolation required

• Resource quotas per team on compute, storage, connections and build capacity, so one team's runaway workload cannot consume the platform. Enforced rather than advisory, because an advisory quota is a report nobody reads.
• Blast-radius separation for the highest-criticality workloads. The payments path should not share a cluster, a database instance or a queue with an internal reporting tool — not because reporting is badly written but because the correlation is unnecessary.
• Separate pools by workload class, not by team, where the workload characteristics genuinely differ: request-serving, batch, builds, and anything untrusted.
• Per-team attribution on every resource, since a noisy neighbour cannot be addressed if it cannot be identified — and the identification must be available during the incident rather than reconstructed afterwards.

The tiering that follows

Most platforms end with a shared tier for the majority and dedicated infrastructure for a small number of critical or very large workloads — the same hybrid that multi-tenant SaaS platforms reach, for the same reasons.

The real design requirement is the ability to move a workload between tiers without a rewrite, which means the same interfaces and the same deployment model regardless of placement.

What must not be shared for a payments platform

The control plane's failure must not stop payment processing. That is static stability applied internally: configuration cached locally, no synchronous platform call on the transaction path, and a failure mode of "serve the previous configuration" rather than "fail".

A platform that makes itself a hard dependency of the most critical path has capped that path's availability at its own, which is rarely what anyone intended.

The governance consequence

Quotas and tiers are business decisions expressed as configuration. Which workload gets dedicated capacity is a question about criticality and cost, and it should be answered by an agreed policy rather than by whoever asked most persistently.