In the deployment stamp pattern, what does a single stamp typically include, and why is the data tier bundled into the stamp rather than left as one shared database behind many stamped app tiers?

## What one stamp bundles A deployment stamp is best understood as a **full vertical slice of the system**, not just a horizontal slice of the compute tier. Concretely, one stamp typically bundles: - The application/API tier — however many app server instances that stamp needs. - Its **own dedicated database or database instance** — this is the critical piece. - Any caching layer used by that tier. - Message queues or event brokers scoped to that stamp. - Often per-stamp background job workers or schedulers. All of these are provisioned together as one deployable, versioned unit — usually via an infrastructure-as-code template that can be re-run to produce a new, identical stamp elsewhere. The stamp is the **atomic unit** of both scaling (you add capacity by adding a whole new stamp) and isolation (a stamp fails, degrades, or gets upgraded independently of every other stamp). ## Why the data tier sits inside the boundary The reason the data tier specifically has to be inside the stamp boundary, rather than factored out into one shared database that many stamped app tiers point at, comes down to where the real constraints live. In most systems, the app/API tier is comparatively easy to scale horizontally — it's usually stateless, so you can add replicas cheaply and a load balancer distributes traffic across them without much coordination cost. The database is where the hard limits actually are: - Maximum connection counts. - IOPS and storage throughput ceilings. - Lock contention between concurrent transactions. - The fact that a single logical database is a natural point of failure — a bad migration, an accidental mass-delete, a corrupted index, a runaway lock. If you stamp out many copies of the app tier but leave them all pointed at one shared database, you've added compute capacity without touching the actual bottleneck — the database still saturates at the same load, and a database-level incident still takes down every tenant across every 'stamp,' which defeats the entire purpose of stamping (both the capacity-ceiling goal and the blast-radius-containment goal go unmet). So the data tier has to move with the app tier as one bundled, independently-provisioned unit for the pattern to deliver on its promises. ## The operational weight of bundling The trade-off of bundling the data tier this way is real operational weight. Each stamp's database needs its own backup schedule, its own point-in-time-recovery posture, its own monitoring for slow queries and connection saturation, and its own capacity headroom sized for the tenants assigned to it. Schema migrations, instead of running once against one database, now have to run against every stamp's database — usually rolled out in waves (a canary stamp first, watched for a period, then the rest) specifically because a bad migration should only ever be able to hurt one stamp at a time, which is the whole point, but it does mean migration tooling has to be built to run safely and idempotently across a fleet rather than assuming a single target. Storage and compute utilization also gets less efficient: | One shared single database | Per-stamp databases | |---|---| | A shared single database can multiplex demand across all tenants and smooth out spikes statistically | Whereas N independent per-stamp databases each need enough headroom for their own assigned tenants' peak load, so you typically carry more aggregate idle capacity than a single pooled system would | ## Failure modes in production Failure modes that show up in production because of this bundling include: - A stamp's database silently approaching its connection or storage ceiling while operators are watching fleet-wide averages that don't surface the one hot stamp. - A migration script that works against a freshly-provisioned stamp's empty schema but fails against an older stamp that has accumulated schema drift from manual hotfixes. - **Cost sprawl**, where many low-traffic stamps each carry a minimum viable database footprint (even a lightly-used tenant group still needs a database sized for baseline availability and backups), so the aggregate infrastructure bill grows faster than aggregate usage would suggest. ## Where it shows up A concrete, named real-world example of this shape is Microsoft's own description of the Deployment Stamps pattern in the Azure Architecture Center, which explicitly defines a stamp as including the application tier and its dependent services and data stores as one unit, and calls out that customers can be assigned to a stamp, multiple customers can share a stamp, or a customer can even get a dedicated stamp for isolation or compliance reasons — all of which only works because the data tier travels with the app tier inside the stamp boundary.