Two teams each deploy their system into multiple geographic units. Team A calls each unit a 'geode': every geode runs the full application, holds a globally-replicated copy of the data, and can serve any user's request. Team B calls each unit a 'stamp': every stamp is a fully isolated deployment that serves only the specific set of tenants assigned to it, with no data sharing between stamps. What is the key architectural difference between these two approaches, and what does it imply for how each team handles a regional outage?

## Why they get conflated Geode and Deployment Stamp are both patterns for running multiple copies of a system in different places, and it's easy to conflate them because both involve 'more than one deployment,' but they solve different problems and make opposite choices about what each unit owns. ## What each unit owns - **In the Geode pattern, the unit of deployment - the geode - is a peer** that is functionally identical to every other geode and, critically, can serve any request from any user, because the application data is replicated across all geodes. There is no concept of 'this geode belongs to these users' - a request from a user in Brazil could, in principle, be served correctly by the geode in Ireland if that's the one routing sends it to, because that geode has, via replication, a usable copy of the relevant data. - **The unit of deployment in the Deployment Stamp pattern - the stamp - is instead a fully isolated, self-contained slice of the system**: its own compute, its own storage, its own copy of the code, deployed independently, but crucially assigned to serve only a specific subset of tenants or customers, with no data sharing to other stamps. A request for a customer assigned to stamp 3 can only be correctly served by stamp 3; no other stamp has that customer's data at all. ## How that cascades Mechanically, this difference cascades into how routing, failure handling, and data architecture all work. | | Geode | Deployment Stamp | |---|---|---| | **Routing** | proximity/health-based and interchangeable - send this request to the nearest healthy geode - because any geode will do | assignment-based - send this tenant's request to the specific stamp it's assigned to - typically via a lookup, a directory service mapping tenant ID to stamp, rather than pure geography, because proximity is irrelevant if the wrong stamp can't serve the request at all | | **When a geode's or a stamp's region fails, the system's response is** | to route that traffic to the remaining geodes, a capacity reduction shared across the whole active-active fleet, invisible to most users if there's enough spare capacity elsewhere | that stamp's specific tenants experience an outage, full stop, until that stamp recovers, unless the architecture separately adds stamp-level disaster recovery, a whole separate concern; the other stamps carry on completely unaffected because they were never involved in serving those tenants anyway | ## Trade-offs in opposite directions The trade-offs run in opposite directions. - **Geode buys resilience-by-substitutability** - lose one geode, others cover for it - at the cost of running full cross-region data replication continuously, and it requires the application to tolerate the reality that data written in one region may be read slightly stale in another. - **Deployment Stamp buys strong tenant isolation**, since one noisy or misbehaving tenant, or one buggy deployment scoped to a stamp, can't affect tenants in other stamps, simpler data architecture with no cross-region replication conflicts to reason about, and the ability to size, scale, and version each stamp independently for its assigned tenant population - at the cost of no automatic cross-stamp failover: if a stamp is down, its tenants are down, and mitigating that requires either accepting the outage window or building separate DR machinery for that specific stamp, which is a different, narrower guarantee than what active-active geodes provide by default. ## Different business shapes They're also frequently used for different business shapes. - **Geode fits products with a single, generally homogeneous user base spread globally**, where the goal is uniformly low latency and high availability for everyone, such as a consumer app or a global API. - **Deployment Stamp fits multi-tenant SaaS products** where tenants need strong isolation from each other - for regulatory/data-residency reasons, for blast-radius containment, or because tenants are sized so differently that one-size-fits-all capacity planning doesn't work - and where 'my region went down' being scoped to only that region's tenants is an acceptable, even desirable, property rather than a defect. ## Composing them, and the question that tells them apart It's worth noting the patterns aren't mutually exclusive at different layers of the same system: a vendor could run Deployment Stamps to isolate large enterprise tenants by data-residency requirement, while each stamp internally is a single-region deployment, or in principle a stamp itself could be built as a smaller geode-like active-active cluster across nearby availability zones for local resilience, without that stamp becoming interchangeable with a stamp on another continent. The key distinguishing question to ask about any multi-region deployment is simply: **if you send a random request to a random unit, can it correctly answer it?** If yes, you're looking at something in the Geode family. If the answer depends on which specific tenant or customer the request is for, you're looking at something in the Deployment Stamp family.