Deployment Stamps
The Deployment Stamps pattern deploys a complete, independent copy of a system — application, storage, configuration — as a self-contained unit called a stamp (or ‘cell’, ‘pod’). Each stamp serves a slice of users or workload; multiple stamps run in parallel for scale-out, isolation, or geographic distribution. A stamp is the unit of deployment, scaling, failure, and recovery. By partitioning users across stamps, you bound the blast radius of any failure to one stamp and scale horizontally by adding stamps.
How it works
A deployment stamp is a complete, self-contained deployment of your system: application servers, databases, caches, queues, configuration. It serves a slice of users (or tenants, or workload). Multiple stamps run in parallel, each serving its own slice, with a routing layer in front that directs users to the right stamp.
Key properties of a stamp:
- Self-contained: each stamp has everything it needs to serve its users — no cross-stamp dependencies for normal operation.
- Independent: failure of one stamp doesn't affect others. Deploy to one stamp doesn't affect others.
- Identical (mostly): stamps run the same software version, the same configuration templates (with per-stamp values). Differences are limited to per-stamp config (region, capacity, tenant assignments).
- Disposable: a stamp can be torn down and rebuilt from infrastructure-as-code. No state is irreplaceable — data is replicated or backed up.
- Bounded blast radius: a stamp's failure affects only its own users.
Common terminology:
- Stamp / cell: the deployment unit (this pattern, AWS cell-based architecture, Stripe Cells).
- Pod: same concept (Slack pods, AWS pod architecture).
- Shard: the data-level equivalent (database shard).
- Region: a geographic deployment, often a single stamp.
A routing layer in front directs users to their stamp:
- Sticky by tenant or user ID — each user is permanently assigned to a stamp.
- By geography — users in Europe go to the EU stamp.
- By capacity — new users go to the stamp with most headroom.
- By feature tier — premium users on a special stamp.
The routing layer is itself a SPOF if not designed carefully — it must be highly available, with its own redundancy (multi-region, DNS-level failover).
Benefits of Deployment Stamps:
- Bounded blast radius — a bad deploy, a corrupting migration, or a runaway query affects only one stamp's worth of users. Stripe's cell-based architecture is designed around this: a bug takes down one cell, not the whole system.
- Scale-out — when one stamp reaches its capacity ceiling (database size, request rate, storage), add another stamp and route new users to it. No need to make one stamp infinitely scalable.
- Gradual rollouts — deploy to stamp 1, watch for 24 hours, deploy to stamp 2, watch, then deploy to all. Roll back just the affected stamp if something breaks. This is safer than rolling deploys within a single deployment.
- Geographic distribution — stamps in different regions route users to the nearest. Combines with Geodes pattern for active-active multi-region.
- Tenant isolation — high-value or security-sensitive tenants get their own stamp. A noisy tenant can be isolated.
- Independent capacity — each stamp can be sized for its workload. A stamp serving premium customers gets more capacity; a stamp serving free users is smaller.
- Easier testing — deploy a candidate version to one stamp, route a small percentage of users there, observe behavior in production.
- Clean disaster recovery — if a stamp's region fails, you can route its users to another stamp (after data sync). The unit of failover is a stamp, not a service.
Costs:
- Operational complexity — operating N stamps is more work than operating 1. Each stamp needs monitoring, alerting, on-call rotation. Tools like Kubernetes Operators and infrastructure-as-code (Terraform, CDK) make this tractable but not free.
- Cross-stamp operations are hard — queries that span stamps (e.g., ‘how many users across all stamps?’) require aggregation across stamps. Typically solved with a separate analytics warehouse.
- Capacity overhead — each stamp needs some baseline capacity (a database, a load balancer). With many small stamps, overhead dominates.
- Stamp migration is expensive — moving a tenant from one stamp to another requires data migration, which is hard for stateful systems.
- The routing layer is critical — must be HA, multi-region, with its own redundancy.
Cell-based architecture is the modern formulation of Deployment Stamps, popularized by AWS and adopted by Stripe, Slack, and others. A ‘cell’ is a stamp with strict rules: no cross-cell calls in the critical path (a request served by cell N must stay in cell N), routing layer is the only cross-cell component, and cells are the unit of failure. The pattern is designed so that a bad deploy, a corrupting migration, or a runaway query is contained within one cell — limiting the blast radius in a way that's impossible with a single monolithic deployment.
Choosing the number and size of stamps:
- Too few stamps: blast radius is large (one stamp serves too many users); no scale-out beyond one stamp's capacity; rollouts are riskier.
- Too many stamps: per-stamp overhead (database, LB, monitoring) dominates; cross-stamp operations become frequent; operational complexity grows.
- Sweet spot: typically 3-10 stamps for a mid-size service. Each stamp serves 10-30% of users. Big enough for efficiency, small enough for bounded blast radius.
Stamp sizing:
- User count per stamp — common rule: 10K-100K users per stamp. Beyond that, blast radius is too large.
- Tenant count per stamp — for B2B: 100-1000 tenants per stamp.
- Database size per stamp — keep each stamp's DB under a few TB; beyond that, maintenance operations (migrations, backups) get slow.
- Request rate per stamp — stay within one region/AZ's capacity headroom.
Migration between stamps is the hard operational problem:
- Routing change — point the user to the new stamp.
- Data migration — copy the user's data from the old stamp to the new. For stateful systems, this is the bottleneck.
- Cutover — switch reads/writes atomically, or do dual-write-and-cutover.
- Cleanup — delete the user's data from the old stamp.
For stateless services, stamp migration is trivial: just change the routing. For stateful systems, plan migration from day one — it will happen.
A bad deployment on your monolithic system takes down all 1 million users for 30 minutes. How would Deployment Stamps have changed the outcome?
Pick one answer.
You're using Deployment Stamps and need to answer ‘how many active users do we have, across all stamps?’ Why is this hard, and how is it typically solved?
Pick one answer.
Engineering mental model
Mental model. Think of Deployment Stamps as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Deployment Stamps mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Deployment Stamps, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = deployment_stamps(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: Deployment Stamps
Change the variables below and predict what breaks first in Deployment Stamps. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Deployment Stamps, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Deployment Stamps. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Deployment Stamps?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Deployment Stamps, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Deployment Stamps, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
A useful engineering lens for Deployment Stamps: define the problem it solves, the simpler design that fails first, the constraint that forces you to introduce this concept, and the new failure modes the concept creates.
Numerical sanity check
Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
Imagine the simplest version of a system using Deployment Stamps. What breaks first as traffic grows by 10×, and what would you change before reaching 100×?
Pick one answer.
What you gain, what you pay
- +Bounded blast radius — failure of one stamp affects only its users.
- +Scale-out by adding stamps — no need for one stamp to scale infinitely.
- +Gradual rollouts — deploy to one stamp, watch, expand.
- +Tenant isolation — high-value or noisy tenants on dedicated stamps.
- +Geographic distribution — stamps in different regions serve nearby users.
- +Clean disaster recovery — failover unit is a stamp, not a service.
- −Operational complexity — N stamps to monitor, deploy, operate.
- −Cross-stamp queries are hard — need an analytics warehouse.
- −Capacity overhead per stamp — database, LB, monitoring baseline.
- −Stamp migration is expensive — moving tenants between stamps requires data migration.
- −Routing layer is a critical SPOF — must be highly available and multi-region.
How this breaks in production
- Routing layer failure — directs users to wrong stamp or no stamp; needs HA and DNS-level failover.
- Bad deploy on one stamp — affects only that stamp's users (which is the point), but you need to detect and roll back fast.
- Data skew — one stamp serves far more users than others; that stamp hits capacity limits.
- Cross-stamp dependencies — if stamps must call each other, blast radius expands; strict cell-based rules forbid this.
- Stamp migration failures — data inconsistency during cutover leaves users in a broken state.
- Capacity headroom erosion — without careful sizing, one stamp's headroom drops below safety margin.
Don't fall into these traps
- •Allowing cross-stamp calls in the critical path — defeats the isolation; strict cell-based rules forbid it.
- •Not monitoring per-stamp capacity — one stamp's saturation is invisible without per-stamp metrics.
- •Underestimating the routing layer — it's the new SPOF; build it HA from day one.
- •Not planning for stamp migration — you will need to move tenants between stamps; design for it.
- •Building too few stamps — saves operational overhead but increases blast radius.
- •Building too many small stamps — per-stamp overhead dominates; operations become expensive.
Real systems using this
How real systems implement this
- Stripe Cells — Stripe partitions its users across independent ‘cells,’ each running a complete stack (API, database, services). A bad deploy or corrupting migration affects one cell's users, not all of Stripe. Stripe has publicly discussed this architecture as the foundation of their blast-radius isolation strategy.
- AWS cell-based architecture — AWS internally uses cell-based architecture to isolate failures. A regression in one cell affects only that cell's tenants. AWS has published guidelines for customers to adopt the same pattern using Route 53, VPC, and per-cell infrastructure.
- Slack cell/pod architecture — Slack partitions workspaces across ‘pods’ — independent deployments with their own infrastructure. A failure in one pod affects only that pod's workspaces. The routing layer directs each workspace to its pod based on a mapping.
Practice saying it out loud
- Q1What is the Deployment Stamps pattern, and what problem does it solve?
- Q2How does Deployment Stamps relate to cell-based architecture? Give an example of a company using it.
- Q3A bad deploy takes down your whole system. How would Deployment Stamps have changed the outcome?
- Q4How do you handle cross-stamp queries like ‘total active users’ in a Deployment Stamps architecture?
- Q5What are the operational costs of running multiple stamps, and how do you decide the right number?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
Geodes