# Architecture Trade-Offs for Security and Platform Teams

> **Intro:** Architecture reviews rarely present a clean “secure vs insecure” choice. More often they present **two valid options with different costs, constraints, and failure modes**. This page focuses on the trade-offs senior engineers repeatedly mediate between product speed, platform simplicity, and security assurance.

## Trade-off 1: shared cluster vs dedicated cluster

### Shared cluster

**Strengths:** better utilization, lower cost, fewer platform surfaces to manage.\
**Risks:** stronger dependence on namespace isolation, policy discipline, and operational rigor.

### Dedicated cluster

**Strengths:** cleaner blast-radius separation, easier exception handling, simpler tenant narratives for audits.\
**Risks:** more operational sprawl, inconsistent guardrails, cost growth, weaker central visibility if standards drift.

**Decision bias:** use dedicated clusters for materially different trust zones, compliance domains, or customer commitments — not simply because a team is loud.

## Trade-off 2: multi-tenant database vs per-tenant database

### Shared multi-tenant store

Best when product velocity, cost, and operational simplicity matter more than maximal isolation.

### Per-tenant store

Best when customer isolation requirements, legal separation, or high-value regulated data justify the operational tax.

**Review question:** can the team prove tenant isolation in code, query paths, background jobs, and support tooling — or are they relying on one narrow control?

## Trade-off 3: self-hosted runners vs SaaS runners

### Self-hosted runners

Pros: more network reach, internal system access, custom tooling.\
Cons: larger trust boundary, harder lifecycle hygiene, greater persistence risk.

### SaaS runners

Pros: simpler lifecycle, better baseline isolation, less platform maintenance.\
Cons: limited network reach, stricter patterns required for internal deployments.

**Rule of thumb:** if the workload truly needs internal access, isolate runners by trust tier and purpose. Do not solve convenience problems with shared privileged runners.

## Trade-off 4: direct internet pulls vs curated internal artifact mirrors

Direct pulls reduce setup friction. Internal mirrors improve provenance control, outage resilience, and policy enforcement.

Choose mirrors when:

* production dependencies matter to uptime or compliance;
* image or package integrity is a recurring concern;
* teams need reviewable approved sources.

## Trade-off 5: public admin plane vs private admin plane

A public admin plane is easier to operate globally but raises exposure and trust requirements. A private admin plane reduces exposure but increases access brokerage complexity.

**Decision point:** if the admin plane can trigger irreversible or high-impact actions, prefer stronger access segmentation even if usability takes a hit.

## The architecture memo structure that works

For each trade-off, document:

* context and constraints;
* risk we are willing to accept;
* controls that must be true for the choice to remain safe;
* telemetry needed to know the choice is still working;
* what would trigger revisiting the decision.

## Design review prompts

* Which option produces the **simplest explainable trust model**?
* Which option fails more safely?
* Which option can product teams operate **without permanent security hand-holding**?
* Which option produces logs and evidence that investigators can actually use?
* Which option scales exception handling more cleanly?

## Cross-links

* [Multi-Tenant SaaS and Admin-Plane Patterns](/architecture-api-crypto-and-identity/index-1/multi-tenant-saas-and-admin-plane-patterns.md)
* [Runner Isolation and Trust Boundaries](/devsecops-cicd-and-supply-chain/index-1/runner-isolation-and-trust-boundaries.md)
* [Trusted Images, Harbor, and Signing](/cloud-kubernetes-and-infrastructure-security/index-1/trusted-images-harbor-and-signing.md)

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/strategy-governance-and-leadership/index-1/architecture-tradeoffs-for-security-and-platform-teams.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.