In a deployment-stamp architecture, how does a platform decide which stamp a new tenant is assigned to, and what happens operationally when a stamp approaches its capacity limit?

## Who owns placement Tenant placement is the piece of glue logic that makes a fleet of otherwise-independent stamps behave like one coherent product. It's owned by what's usually called a **control plane**, **tenant directory**, or **fleet manager** — a small, separately-scaled service (or set of services) that is shared across the whole system, unlike the stamps themselves. Its core job is to maintain a mapping from tenant identity to stamp, and to make the placement decision at signup time: when a new tenant is created, the control plane consults its knowledge of each stamp's current load (number of tenants, database size, request volume, or whatever metric the team uses as a capacity proxy) and applies a placement policy. ## The placement policies Common policies are: - 'Pick the stamp with the most free capacity.' - Round-robin across stamps below a load threshold. - For tenants with special requirements, route straight to a dedicated, isolated stamp reserved for that purpose — a large enterprise customer with contractual isolation requirements, or a customer subject to a specific data-residency rule. This directory then has to be consulted by the routing layer (API gateway, DNS-based routing, or an ingress rule) on every incoming request, so it needs to be fast and highly available — it sits on the critical path for every tenant even though it holds no tenant application data itself. ## Why placement matters so much The reason this placement logic matters so much is that a stamp is a **bounded-capacity unit**, and bad placement decisions compound over time. Stamps are typically sized with some target load in mind, and once a stamp's tenant population pushes it toward its database connection ceiling, storage limit, or latency SLO, the operational choices are limited and none of them are free. ## The three levers when a stamp fills up | Lever | What it does | |---|---| | Stop assigning new tenants | The simplest response is to stop assigning new tenants to that stamp and direct future growth to a freshly-provisioned stamp — cheap to execute, but it does nothing about the stamp that's already full and doesn't help if an existing tenant on that stamp keeps growing | | Vertical growth | The next lever is vertical: grow that stamp's database or app-tier resources, if the underlying infrastructure has headroom — often the first response because it requires no data movement, but it only buys time before hitting the next ceiling | | Tenant migration | The heavier lever is tenant migration: physically moving one or more existing tenants from an over-loaded stamp to a less-loaded one | Migration means replicating the tenant's data (schema, rows, blobs, whatever is tenant-scoped) into the destination stamp's database, then cutting traffic over — commonly done either via a **maintenance window** (simplest, but visible downtime for that tenant) or a **dual-write/backfill approach** where writes go to both stamps during a transition period and reads cut over once the backfill catches up (more complex to build correctly but avoids visible downtime). Either way, the directory has to be updated atomically with the cutover so requests start routing to the new stamp at the right moment, and any in-flight requests during the cutover window need careful handling to avoid split-brain writes landing on the wrong stamp. ## When placement goes wrong Getting placement wrong early is expensive precisely because migration is the expensive escape hatch. - **A common real-world failure mode** is placing several large or fast-growing tenants onto the same stamp early on (because that stamp happened to have room at signup time), only to discover months later that the stamp is now disproportionately loaded relative to its siblings, forcing an unplanned, high-risk migration under time pressure rather than a calm, proactive one. - **Another failure mode is a control plane outage or staleness bug**: if the tenant directory's view of stamp load gets stale (e.g., a metrics pipeline lag), new tenants can keep getting routed onto an already-saturated stamp, degrading service for everyone already there. Teams operating at scale generally build **proactive rebalancing** — periodically identifying stamps trending toward their limits and migrating a few tenants preemptively, during low-traffic windows, rather than waiting for a hard ceiling to force an emergency migration. This tenant-placement-and-rebalancing problem is one of the main reasons the deployment stamp pattern is described as trading raw infrastructure simplicity for operational sophistication: the stamps themselves are conceptually simple to replicate, but the fleet-level logic of who goes where, and how they move, is genuinely hard distributed-systems work.