Imagine a popular restaurant that keeps cramming more tables into one dining room. Eventually the kitchen, the single host stand, and the one overworked manager all become bottlenecks — and one spilled tray ruins everyone's night. The smarter move is to open identical branches: same menu, same layout, same staffing, each serving its own crowd.
The Deployment Stamps pattern is that idea for software. Instead of growing one massive shared system, you stamp out complete, independent copies and route each group of customers to one of them.
The problem
A single shared deployment that serves everyone runs into hard ceilings. There's a limit to how far you can scale one database, one cache, or one regional footprint before contention and quotas bite.
Worse, everything shares fate. One noisy tenant hammering the system degrades every other customer. A bad release rolls out to your entire user base at once. A regional outage takes down all your traffic. And big enterprise customers often demand data residency or isolation guarantees that a single mixed system simply can't offer.
Noisy TenantOne heavy customer hammering the shared system.
Shared StackA single deployment serving every tenant — the bottleneck.
Shared DataOne database for all tenants; contention degrades everyone.
How it works
You define a stamp — sometimes called a scale unit — as a complete, self-contained slice of the whole application: its compute, its database, its cache, its queues, all of it. Crucially, a stamp is described as infrastructure-as-code so you can provision an identical new one with a single repeatable run.
Each stamp serves a bounded set of tenants (or a region's traffic). When you outgrow capacity, you don't make an existing stamp bigger — you deploy another stamp. A thin traffic-routing layer sits in front and maps each incoming request to its home stamp, typically by tenant ID or geography. The diagram below shows the router fanning requests out to several identical, isolated stamps.
- TenantsGroups of customers, each assigned to one stamp.
- Traffic RouterLooks up tenant → stamp and forwards. The only shared piece.
- StampA complete, self-contained copy of the app — a scale unit.
- Stamp DataEach stamp owns its own data; stamps share nothing.
The router is the one shared thing — keep it dumb. The routing layer should do almost nothing but look up tenant → stamp and forward the request. Put business logic, sessions, or shared state in it and you've recreated the single bottleneck the pattern exists to eliminate.
Why isolation pays off
Because stamps share nothing, your blast radius shrinks to one stamp. You can roll a risky release out to a single low-traffic stamp first, watch it, and only then ripple it across the fleet — a far safer story than a big-bang deploy.
Isolation also unlocks placement flexibility. A demanding enterprise customer can get their own dedicated stamp in a specific region for compliance, while thousands of small customers share a multi-tenant stamp. It's a natural fit alongside microservices: each stamp can itself be a full mesh of services, just replicated as a unit.
When to use it
Reach for deployment stamps when you're a multi-tenant SaaS bumping into single-system scale limits, when you need tenant isolation or data residency, or when you want to cap the blast radius of deploys and failures across a large customer base.
Skip it when you're small. Running many copies multiplies your operational surface — every stamp needs monitoring, patching, and capacity planning — so it's only worth it once you have robust automation and enough scale to justify the overhead. For a young product on one modest database, plain scaling is simpler and cheaper.