Deployment Stamp

## What a stamp actually is The deployment stamp pattern — sometimes called a **scale unit** — treats the entire application stack as a stampable unit: the web/app tier, the database, message queues, caches, and any supporting infrastructure are all deployed together as one self-contained copy, and that copy is then replicated across the system to serve different tenant groups. This is fundamentally different from the more familiar approach of scaling a single shared deployment: instead of adding more app servers behind a load balancer that all point at one shared database, or vertically growing that one database, you create additional whole copies of the stack — stamp 1, stamp 2, stamp 3 — each with its own app instances and its own database, and you route different tenants to different stamps. ## The pieces you have to build Mechanically, building this out requires a few pieces working together. 1. **First, the stamp itself must be fully automatable** — infrastructure-as-code templates (`ARM/Bicep`, `Terraform`, `Helm` charts, whatever the platform uses) that can spin up a complete, working copy of the stack from scratch, because you'll be doing this repeatedly as you add capacity. 2. **Second, you need a control plane or fleet manager**: a lightweight, typically globally-shared service that knows which tenant lives on which stamp, handles new-tenant provisioning (deciding which existing stamp has room, or triggering a new stamp), and exposes that mapping to the routing layer. 3. **Third, the routing layer** (API gateway, DNS, or an ingress rule) uses that mapping to send each incoming request to the correct stamp — this is deliberately kept separate from the **geode pattern**, which is about routing to the geographically nearest stamp; deployment stamping itself is agnostic to geography and is really about capacity and isolation boundaries, not latency. ## Why the pattern exists The reason this pattern exists is that a single shared deployment eventually hits hard ceilings that no amount of vertical scaling fixes: - A database has a **maximum practical connection count and IOPS ceiling**. - A **noisy tenant** running a huge batch job or an unbounded query can degrade latency for every other tenant sharing that database. - A bad migration or a corrupted index in the shared database is a blast radius covering **100% of customers**. - Regulatory or contractual requirements sometimes force certain customers to have their data physically or logically separated from others (data residency, dedicated-tenant contracts). Deployment stamps give you: - A **bounded blast radius** — an outage or bad deploy on stamp 7 only affects the tenants on stamp 7. - A **natural capacity ceiling per stamp** — each stamp only needs to handle its assigned tenant load, so you never approach the absolute limits of a single database instance. - A **placement lever for special requirements** — you can stamp out a dedicated, isolated instance for a regulated or premium customer. ## The trade-offs The trade-offs are substantial and mostly operational. - **Every stamp is a full deployment**: it needs its own monitoring, its own on-call visibility, its own capacity headroom, its own backup and DR posture, and its own rollout during a release — so a change that used to mean 'deploy once' now means 'roll out across N stamps,' usually in waves (canary stamp first, then the rest) to limit blast radius on the rollout itself. - **Anything that needs a cross-tenant view** — a global admin dashboard, cross-tenant analytics, a 'search across everything' feature, billing aggregation — now has to fan out across every stamp and merge results, which is materially harder than one query against one shared database. - **Tenant placement and rebalancing become their own engineering problem**: you need logic to decide which stamp a new tenant lands on (often by remaining capacity), and a migration path for moving a tenant between stamps when one gets too full or a customer needs to move to a dedicated/regulated stamp — that migration typically means copying that tenant's data to a new database and cutting traffic over, which is nontrivial to do with minimal downtime. - **Utilization is also worse than a single pooled deployment**: stamps are sized with headroom for their assigned tenants, so you often have idle capacity sitting unused across many stamps rather than one large pool that smooths out demand via statistical multiplexing. ## Failure modes in production In production, stamp-related failures usually show up as: - A stamp silently running out of headroom while other stamps sit underused — a placement/rebalancing gap. - A config or schema drift between stamps because an automation script only partially ran on one of them. - An operational blind spot where alerting is set up per-stamp and a slow-burning issue on one under-monitored stamp goes unnoticed because dashboards default to fleet-wide averages that dilute it. ## Where it shows up A well-known real-world instance of this pattern is how many large multi-tenant SaaS platforms (this shape is documented as a standard pattern in Microsoft's Azure Architecture Center under 'Deployment Stamps') shard their customer base across independently deployed stamps, each with its own database, and layer a lightweight tenant-directory service on top to route sign-ins and API calls to the right stamp.