Deployment Stamps

The Deployment Stamps pattern (also called the service stamp or scale unit pattern) provisions multiple independent copies of an application and its resources, each called a stamp. Each stamp serves a subset of users or tenants and runs in isolation from the others.

The problem is scaling and isolating a multi-tenant system beyond what a single shared deployment can handle. A shared stack creates noisy-neighbor effects, a single blast radius, and scaling limits tied to one set of resources.

How It Works

A stamp is a self-contained unit: compute, database, storage, and supporting services deployed together, usually from the same infrastructure-as-code template. Tenants are assigned to stamps. A routing or traffic-management layer maps each request to its tenant's stamp, often via a lookup table.

To scale, you deploy more stamps rather than growing one stack. Because stamps are independent, a failure or a bad deployment in one stamp does not affect tenants in others. Stamps can be placed in different regions, sized differently for different tenant tiers, and updated in waves to limit risk.

When to Use It

Use it for multi-tenant SaaS that must isolate tenants, scale horizontally past single-stack ceilings, and contain failures. It suits regulated tenants needing dedicated resources or specific regions, and large customers warranting their own stamp.

Avoid it for small single-tenant apps or where a single elastic deployment comfortably handles the load, since per-stamp overhead multiplies operational cost.

Trade-offs

Managing many stamps multiplies deployment, monitoring, and cost. You need robust automation to provision, update, and observe stamps uniformly, plus a reliable tenant-to-stamp routing and onboarding process. Cross-stamp operations (analytics, global search) become harder because data is partitioned by stamp.

The upside is strong isolation, predictable scaling by adding units, and a small blast radius for failures and rollouts.

Related Patterns

It resembles the Geode pattern but stamps are not interchangeable; each serves specific tenants. Sharding partitions data within or across stamps. An External Configuration Store and the tenant routing table coordinate which stamp owns which tenant.

Example

A B2B analytics SaaS deploys each stamp with its own Kubernetes cluster, database, and cache via Terraform. Small customers share stamps holding a few hundred tenants each; an enterprise customer gets a dedicated stamp in its required region. A routing service maps incoming requests by tenant ID to the right stamp. To grow, the team deploys a new stamp from the template and onboards tenants to it; a faulty release rolled out to one stamp affects only its tenants.