Distributed Systems: Scenario-Based Questions

Active-active architectures serve traffic from multiple regions simultaneously to improve latency, resilience, and availability. But they also introduce consistency, replication, and failover complexities.

🌍 Core Design Goals

• Low latency for global users
• Fault isolation between regions
• High availability and disaster recovery

🔧 Architectural Patterns

• Global Load Balancing: DNS or Anycast routing to the nearest region
• Geo-Replicated Databases: Multi-master (e.g., CockroachDB, Cosmos DB) or leader-follower setups
• Eventual Consistency: Use conflict-free data types (CRDTs) or reconciliation strategies

📦 Data Considerations

• Partition by geography or customer (e.g., EU traffic stays in EU)
• De-dupe and resolve conflicts during replication
• Use idempotent writes to prevent data loss on retries

🛠️ Infrastructure & Tools

• Cloudflare Load Balancer, AWS Global Accelerator, GCP Cloud Load Balancing
• DynamoDB Global Tables, Cosmos DB, Spanner
• Kafka MirrorMaker or event mesh across regions

✅ Best Practices

• Health-check and monitor region-specific performance
• Deploy in canary mode across regions to limit blast radius
• Simulate region failure and test recovery paths

🚫 Common Pitfalls

• Assuming strong consistency across regions by default
• Coupling tightly with one region’s state
• No clear source of truth or conflict resolution logic

📌 Final Insight

Multi-region active-active is powerful but complex. Start with clear consistency and failover strategies, test them relentlessly, and design for the network’s reality — not idealism.