State Management and Data Gravity in Global Load Balancing

The State Challenge
Global Load Balancing only delivers value when your application architecture can tolerate users moving between regions. Stateless services and globally replicated caches make region switching trivial: every region can serve any request independently. The challenge emerges with stateful writes, which require careful placement strategies to maintain consistency while minimizing cross-region latency penalties. State creates "data gravity" that pulls users toward specific regions.
Pattern 1: Single Writer Per Shard
Route all writes for a given partition to a designated home region, with asynchronous replication to other regions for read scaling. This avoids distributed consensus overhead (which would add cross-region RTT to every write) but creates affinity: users must reach their home region for writes, potentially adding cross-continental RTT. Example: User accounts partitioned by user ID, each partition assigned a home region. Reads work anywhere; writes route to home. Replication lag of 100-500ms is typical for cross-region async replication.
Pattern 2: Multi-Writer with Conflict Resolution
Allow writes anywhere using CRDTs (Conflict-free Replicated Data Types, data structures that automatically merge concurrent updates without coordination) or version vectors to resolve conflicts. This enables true active-active where any region handles any write. The trade-off: pushes complexity into application logic and limits data models to those that merge cleanly. Counters, sets, and last-writer-wins maps work well. Arbitrary relational data does not. Conflict resolution adds 10-50ms processing overhead for merging.
Pattern 3: Read Local Write Home
Keep fast read paths local while routing writes through a longer path to the authoritative region. For read-heavy workloads (video streaming, content delivery, product catalogs), this is ideal: 95%+ of requests are reads served locally with sub-10ms latency. The occasional write (updating preferences, saving progress) tolerates 100-200ms additional latency for the cross-region hop. Video streaming services use this extensively: serve video segments from local cache, route metadata writes to home region.
Cross-Region Cost Economics
Synchronous cross-region calls on critical paths multiply latency disastrously. A service making 5 cross-region RPCs at 80ms each adds 400ms to user latency, destroying GLB benefits. Egress costs compound: at $0.02-0.09/GB for inter-region transfer, a service doing 10 Gbps cross-region costs $50,000-225,000/month in bandwidth alone. Design principle: pin chatty microservices within regions; use async replication for global state.
Key Insight: State creates data gravity that limits GLB effectiveness. The best architectures minimize cross-region dependencies: stateless services, aggressive caching, async replication for writes. Synchronous cross-region calls destroy the latency benefits GLB provides.

💡 Key Takeaways

✓Single writer per shard: writes route to home region, async replication for reads; avoids consensus but creates affinity

✓Multi-writer with CRDTs: writes anywhere with automatic conflict resolution; limited to merge-friendly data structures

✓Read local write home: 95%+ reads served locally at sub-10ms; occasional writes tolerate 100-200ms cross-region hop

✓Cross-region cost: 5 RPCs at 80ms each = 400ms added latency; 10 Gbps cross-region = $50K-225K/month egress

📌 Interview Tips

1Explain single-writer: user accounts partitioned by ID, each partition has home region, writes route there, async replication for reads

2Describe read-local-write-home for streaming: video segments from local cache, metadata writes (progress, preferences) to home region

3Calculate cross-region cost impact: 5 synchronous RPCs at 80ms each adds 400ms, negating GLB latency benefits

← Back to Global Load Balancing Overview