Many production geode deployments route a given user or account consistently to the same 'home' geode under normal conditions, even though every geode is technically capable of serving any request. Why do teams add this kind of routing stickiness on top of an active-active geode design, and what do they give up when a user's home geode becomes unavailable and traffic reroutes elsewhere?

## The extra layer on top Active-active geode deployments promise that any geode can serve any request, but in practice most production systems that use this pattern add an extra layer on top: under normal operation, a given user or account is consistently routed to the same **'home' geode** rather than being bounced between geodes on every request based purely on momentary network proximity. This might sound like it's giving up some of the pattern's flexibility, and it is, deliberately, because it solves a real problem that pure proximity-based routing leaves unsolved. ## Replication lag versus what a user perceives The problem is **replication lag** interacting with a user's own perception of consistency. Even a fast, well-run replication system takes some non-zero amount of time - milliseconds to low seconds, sometimes more under load - to propagate a write made in one geode to the copies held by the others. If a user's requests are routed purely by momentary proximity or load, it's entirely possible for consecutive requests from the same user to land on different geodes: 1. they submit a change on one request, 2. and a follow-up request lands on a different geode where that write hasn't arrived yet, so the change appears to have vanished. This is confusing and looks like a bug to the user, even though the system is behaving exactly as designed - it's a **UX/product problem** layered on top of a technically-correct eventually-consistent system. Pinning a given user to one geode under normal conditions sidesteps this specific issue: since that user's own reads and writes both happen against the same local copy, from their point of view the system behaves as if it were immediately consistent, because there's no cross-geode race for their own actions to lose. ## The secondary benefit: fewer write conflicts There's a secondary benefit too: reducing the surface area for **write conflicts**. If a given user's account data is, in the common case, only ever being written from one geode at a time, the odds of two geodes independently accepting conflicting writes to the same record collapse dramatically, since conflicts require near-simultaneous writes from different origins - something that mostly only happens during the exact moment routing shifts a user from one geode to another. This doesn't make conflict handling unnecessary, it's still needed for the failover case, but it makes it a much rarer event to actually deal with in practice rather than a routine background occurrence. ## How the stickiness is implemented The mechanism for this stickiness is usually straightforward: - **a directory or lookup keyed by user/account ID** - sometimes just the user's initial signup region, sometimes recalculated - determines which geode is home for that user, - and **the routing layer consults that mapping** instead of, or in addition to, pure network proximity for authenticated requests. ## What it costs at failover The cost becomes visible specifically during a failover, which is exactly when the pattern's resilience benefit is supposed to shine. If a user's home geode becomes unavailable, the routing layer sends them to a different, healthy geode - but that geode's copy of the user's data reflects whatever had already replicated in before the home geode went down, which might lag behind the very latest writes the user made just before the outage. - **The user can see data that looks like it reverted slightly** - an item removed from a cart reappears, a settings change looks unsaved - until either replication catches up, if the home geode partially recovers and finishes propagating. - **Or, in the worst case,** the home geode had accepted a write that never got replicated out at all before failing, meaning that specific write is genuinely lost or has to be manually reconciled. - **Additionally, if the outage is prolonged** and the user keeps interacting with the new, temporary geode, there's now a second stream of writes for that user happening on a geode other than their normal home, so when the original home geode comes back, the system has to reconcile two sets of changes for the same user rather than a single consistent history - exactly the conflict-resolution work the affinity strategy was designed to minimize, now unavoidable specifically for users who were mid-session during the failover. ## The practical upshot The practical upshot is that home-geode affinity trades a small amount of the pattern's theoretical flexibility, any geode serving any request at any moment, for a large improvement in everyday user-perceived consistency, while concentrating the harder consistency problems into the relatively rare and bounded window of an actual regional failover, rather than spreading them across every request all the time. Teams that skip this and route purely by proximity tend to discover the 'my change disappeared' complaint pattern in production before they discover the fix.