magnus919_agent-skills/capacity-and-cost-engineering/references/multi-tenant-capacity-and-unit-cost.md

Multi-Tenant Capacity and Unit Cost

Use this reference when a shared service serves multiple tenants whose demand, promises, or resource footprints differ. The purpose is to produce capacity and cost evidence, not to choose the SaaS domain model or security controls.

Start with distributions

Represent demand as tenant profiles rather than one aggregate average. For each profile, record the demand units, request or job mix, payload or object size, concurrency, burst shape, background work, storage growth, and tier or placement promise. Use observed tenant cohorts where possible and label synthetic profiles as assumptions. Preserve the distribution's shape: a small number of very large tenants can dominate a pooled system even when the mean tenant looks modest.

Useful views include:

• per-tenant time series for rate, concurrency, queue depth, storage, and work;
• a distribution across tenants for each resource, with the statistic chosen for the decision rather than a default percentile;
• joint views that show whether high demand, large objects, and burstiness occur in the same tenants;
• a scenario for new, growing, dormant, migrating, and unusually hot tenants;
• confidence and provenance for every profile, including sampling bias and omitted tenants.

Do not substitute a global average, a single representative tenant, or an arbitrary percentile for the distribution. If a percentile or cap is selected, explain the user promise, failure consequence, and evidence that make it useful.

Find skew and hot tenants

Map the demand profile onto the resource boundary that can saturate: CPU, memory, connections, partitions, IOPS, queue workers, cache capacity, search shards, network, or an external quota. Partition skew is a separate question from request skew. A tenant may be moderate overall but overload one partition, key range, shard, worker pool, or availability zone.

For each hot-tenant or skew scenario, record:

1. the detection signal and the identity granularity available to operators;
2. the resource and neighboring tenants exposed to contention;
3. the admission, queueing, scheduling, placement, throttling, or isolation response;
4. the impact on the hot tenant and on protected tenants;
5. the recovery and rebalancing path, including backlog and data-integrity checks; and
6. the evidence boundary, workload mix, duration, and unresolved gaps.

Route isolation mechanisms, authorization, and noisy-neighbor threat analysis to secure-software-engineering. Route the end-to-end tenancy, lifecycle, and placement architecture to multi-tenant-saas-architecture.

Compare pooled and siloed headroom

For a pooled deployment, model shared baseline, aggregate demand distribution, correlation between tenants, admission behavior, and the headroom needed to protect the promised service during a hot-tenant or dependency scenario. Pooling can benefit from imperfectly correlated demand, but its usable headroom is bounded by the resource with the worst contention or skew, not by a fleet average.

For a siloed or dedicated deployment, model the per-tenant baseline, reserved headroom, failure-domain requirement, idle capacity, and operational overhead. Do not assume that a silo is cheaper or more reliable. Compare the scenarios that matter: ordinary load, tenant growth, burst, tenant failure, placement movement, and loss of a resource or failure domain. Hybrid placement should show which resources are pooled and which are dedicated, with separate evidence for each.

Headroom is a decision variable. State what it protects, the time horizon and provisioning lead time, the observed saturation behavior, and the cost of unused capacity. Never present one utilization or headroom percentage as a general rule.

Translate tier promises into capacity controls

For every tier promise, connect the customer-visible statement to a measurable capacity behavior: sustained demand, burst allowance, concurrency, storage or job limit, latency treatment, priority, isolation, or recovery treatment. Record whether the promise is a contract, a product default, or an operational goal.

Quotas and rate limits are controls, not proof of capacity. Define the scope, steady behavior, burst behavior, response to excess, fairness objective, and backpressure or degradation path. Admission should preserve the critical path and make rejection or delay explicit rather than allowing unbounded queues and retry amplification.

Fairness is contextual. Choose the fairness policy from the promise and resource: weighted shares, reserved capacity, tier priority, work conservation, isolation, or another explicit rule. Measure both protected-tenant outcomes and the consequence for the tenant being constrained. Do not use a universal fairness ratio, quota, utilization target, or rejection threshold. A threshold is valid only when its rationale, owner, workload, and review trigger are recorded.

Produce tenant-variable unit cost

Separate the cost model into at least:

• platform baseline: costs that remain for the service or pool when tenant demand is absent or minimal;
• tenant-variable cost: incremental compute, storage, transfer, operations, or other resource cost attributable to a tenant profile; and
• allocation of shared cost: the chosen method for assigning pooled cost, such as measured consumption, reserved entitlement, capacity reservation, or a transparent blended allocation.

Report direct or marginal cost separately from fully allocated cost. Use the same period, scope, and demand denominator. For tenant t, a useful model is:

tenant cost(t) = allocated baseline(t) + measured variable cost(t)
tenant unit cost(t) = tenant cost(t) / tenant demand units(t)

The allocation method must explain how idle pooled capacity, shared control-plane work, replication, support, backups, and failure-domain redundancy are treated. Keep fixed commitments separate from costs that change with demand. Segment units by materially different work types rather than averaging cheap metadata work with expensive jobs. Route revenue, pricing, margin, and commercial packaging to financial-modeling; route cost tags, billing exports, and resource policy implementation to platform-engineering.

Evidence standard

Before approving a tenant capacity or unit-cost claim, require representative per-tenant load and soak evidence. The test should exercise the relevant tenant distribution concurrently, include hot and skewed profiles, use production-like data and placement, and observe tenant-level and shared-resource outcomes. Record latency, errors, queueing, throttling, admission decisions, resource saturation, partition balance, backlog recovery, and cost inputs.

Component benchmarks can explain a mapping, but they do not establish end-to-end fairness or pooled headroom. A fleet aggregate can show total spend, but it does not establish tenant-variable cost. If representative evidence is unavailable, the output is a model with an explicit gap and a required test, not a validated capacity claim.

Completion check

Stop when the model names the tenant distribution, hot/skew scenario, pooled or siloed headroom choice, tier promise, quota/admission behavior, fairness policy, baseline and variable cost allocation, representative per-tenant load/soak evidence, owners, and unresolved assumptions. Escalate a promise that cannot be supported without silently weakening reliability, privacy, security, or user outcomes.