Geodes

The Geodes pattern, named after polyhedral structures that tile a sphere (like a geodesic dome), is the cloud-architecture pattern for globally distributed active-active backends. The name evokes the idea of tiling the planet with deployment regions, each serving nearby users.

Key properties:

• Multiple regions, all active — every region serves live user traffic. No stand-by regions waiting for failover.
• Full stack in each region — application, database, cache, queues. Each region is self-sufficient.
• Data replication across regions — writes in one region propagate to others. This is the hard part.
• User routing — a global routing layer (DNS, anycast, latency-based routing) directs each user to the nearest active region.
• Region failure is graceful — if a region dies, its users are redirected to other regions.

The routing layer is usually:

• Latency-based DNS (Route 53 latency routing, Cloudflare load balancer) — picks the region with lowest latency to the user.
• Anycast — the same IP is advertised from multiple regions; BGP routing sends the user to the nearest.
• Geo-DNS — explicit geographic mapping (EU users go to EU regions).
• HTTP redirect — a global front service redirects to a region-specific URL.

The critical challenge is data replication:

• Writes must propagate between regions for the system to be globally consistent.
• Replication latency introduces a window where two regions disagree.
• Conflict resolution is required when two regions accept writes to the same data simultaneously.

Replication strategies:

• Async multi-master — each region accepts writes locally and replicates asynchronously. Eventually consistent. Conflicts possible.
• Sync multi-master — writes are replicated synchronously before acknowledgement. Strong consistency but high write latency (cross-region round-trip).
• Single writer (leader) — one region is the leader for writes; others are read replicas. Simpler consistency but write latency for non-leader regions.
• Per-partition leaders — each partition has its own leader region (DynamoDB Global Tables, Spanner). Distributes write load.
• CRDTs / last-writer-wins — application-level conflict resolution. Works for some data (counters, sets), not all.

Data replication is the crux of Geodes. Three models, each with trade-offs:

1. Asynchronous multi-master (eventual consistency) — each region accepts writes locally, replicates async. Lowest write latency, but conflicts possible. Used by: DynamoDB Global Tables, Cassandra multi-region, CouchDB. Resolution: last-writer-wins, CRDTs, or application-level merge. Suitable for: counters, content (posts, comments), state where brief inconsistency is acceptable. Not suitable for: financial transactions, inventory, anything requiring strong consistency.

2. Synchronous multi-master (strong consistency) — writes are committed across all regions before acknowledgement. Strong consistency, but write latency = cross-region round-trip (~100-300ms). Used by: Spanner, CockroachDB, FoundationDB. Suitable for: financial systems, anything requiring linearizability. Trade-off: write latency, throughput limits, complexity.

3. Single leader (leader-follower) — one region is the leader for writes; others are read replicas. Writes go to the leader (high latency for non-leader regions), reads go to the local replica (low latency everywhere). Used by: Postgres with logical replication, Aurora Global Database, MongoDB replica sets. Trade-off: write latency for non-leader regions; leader is a SPOF (needs failover).

4. Per-partition leaders — each partition has its own leader; different partitions can be led by different regions. Distributes write load. Used by: Spanner, DynamoDB Global Tables (with per-key leaders), Cassandra. Combines low write latency for most partitions with strong consistency.

Conflict resolution is the hard problem when async multi-master is used:

• Last-writer-wins — simple but lossy; the losing write is silently overwritten.
• Vector clocks / version vectors — detect concurrent writes; application resolves.
• CRDTs (Conflict-free Replicated Data Types) — data structures that merge deterministically; counters, sets, maps. Used by: Riak, Redis CRDT, AntidoteDB.
• Application-level merge — the application knows how to combine two versions (e.g., a shopping cart merges items).
• Avoid conflicts by design — partition writes by user/tenant so each user only writes in one region at a time. Most practical systems do this.

When to use Geodes:

• Global user base with latency expectations — users in Asia shouldn't wait 200ms to reach a us-east-1 backend.
• Region failure is unacceptable — SLAs require surviving a region outage without user impact.
• Data residency requirements — EU users' data must stay in EU; Geodes lets you keep each region's data local.
• Read-heavy workloads — reads can be served from any region; Geodes works well for read-heavy traffic.
• Linear scale with regions — adding a region adds capacity linearly.

When NOT to use Geodes:

• Single-region user base — if all your users are in one country, multi-region adds cost without benefit.
• Strong consistency required everywhere — sync multi-master is expensive; sync leader writes have high latency for non-leader regions.
• Write-heavy workload — writes are the hard problem; sync writes are slow, async writes risk conflicts.
• Small team — operating multi-region active-active is complex and expensive. Most teams shouldn't.
• Cost-sensitive — running multiple full stacks doubles or triples the bill.

Common operational concerns:

• Routing layer is a critical SPOF — must be HA, multi-region, with DNS-level failover (Route 53, Cloudflare).
• Per-region monitoring — each region needs its own dashboards, alerts, on-call rotation.
• Region failover — when a region dies, its traffic shifts to others. The other regions must have headroom to absorb the extra load.
• Replication lag monitoring — if lag grows, regions drift; user-visible inconsistency grows.
• Testing failover — must be exercised regularly (GameDays, chaos engineering) to ensure it works when needed.

Mental model. Think of Geodes as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Geodes mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.

Answer this without notes: When would you choose Geodes, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

Back-of-the-envelope reasoning beats fake precision. State your traffic, payload, concurrency and growth assumptions explicitly, then calculate enough to know whether the current architecture is orders of magnitude away from the target.