India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Active-Active Resilience: Serving from Two Regions at Once
Active-active resilience is an architecture in which two or more regions serve production traffic simultaneously, each able to take the full load if another fails, so a regional outage causes reduced capacity rather than downtime. NTSPL designs active-active on AWS, Azure and Google Cloud for consumer platforms where even minutes of outage are unacceptable.
Delivered on
In scope
Why Active-Active Is a Data Design Problem First
Active-active is the most demanding DR pattern because the hard part is not infrastructure; it is data. Two regions accepting writes for the same customer can produce duplicate orders, lost cart items or a wallet balance that differs by region. Teams that copy their single-region design into a second region and put a latency-based DNS record in front usually discover this during the first partial outage, when traffic flips back and forth and reconciliation takes a week. Active-active also roughly doubles infrastructure cost, so it must be confined to the services that truly need it.
NTSPL designs active-active from the data model outward. We classify every entity by how it may be written: globally replicated with last-writer-wins, home-region writes with global reads, or strictly single-writer with failover. APIs are made idempotent with client-supplied request keys. Traffic is split by cell or user so each region owns a predictable share. Then we prove it with region evacuation drills, where one region's traffic is drained deliberately while customers continue to transact.
Platforms Where Downtime Is Measured in Lost Customers per Minute
Signals you need Active Active Resilience
- A few minutes of outage costs more than INR 25-50 lakh, or causes measurable customer churn on a consumer app with millions of users.
- Your warm standby drills meet RTO but the business still cannot accept the 5-15 minute gap during peak events such as sales or tournaments.
- You already need two regions for capacity or latency, for example north and south India user bases or regional data residency.
- Core entities such as carts, sessions, player profiles or catalogues can tolerate eventual consistency of a second or two.
- Engineering teams can change application code, not just infrastructure, over a 3-6 month programme.
When to choose something else
- The system is a monolith on a single-writer relational database that cannot be partitioned. Warm Standby DR delivers minutes of RTO without a rewrite.
- The data requires strict global ordering, such as a core banking ledger or exchange order book, and you cannot use a globally consistent database. Use single-writer with fast failover instead.
- Budget allows roughly 30-50% extra for DR, not 80-120%. Pick warm standby and invest the difference in drills.
What an Active-Active Programme Covers
Data classification for writes
Every entity assigned to multi-writer replication, home-region ownership or single-writer failover, with the conflict rule documented.
Multi-region data services
Global tables, multi-region write databases or replicated wide-column stores configured per entity class, plus regional caches.
Idempotency and retries
Request keys on every mutating API, deduplication stores and retry policies so a request replayed in the other region does not double-execute.
Cell and routing design
Users or tenants assigned to cells with a home region; latency or weighted routing with the ability to drain a region in one action.
Regional independence
No synchronous cross-region calls on the request path; each region has its own identity tokens validation, secrets, queues and caches.
Evacuation drills and reconciliation
Planned region drains under real traffic, plus automated reconciliation jobs that detect divergent records after an event.
How Active Active Resilience Works, Step by Step
Cell-Based Active-Active Topology with Classified Data Writes
Users are routed to a home region by cell, and each region runs a complete, independent stack. Data replicates according to its write class, so most entities accept writes anywhere while a small set stays single-writer, and a region can be drained without code changes.
Select any component
Cell-Based Active-Active Topology with Classified Data Writes: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
Multi-Region Write and Routing Services by Provider
DynamoDB global tables provide multi-active replication between Mumbai and Hyderabad; Application Recovery Controller routing controls drain a Region deliberately rather than waiting for health checks.
Cosmos DB accounts with multi-region writes across Central India and South India use configurable conflict resolution; Front Door distributes and drains traffic between regional origins.
Bigtable instances with clusters in Mumbai and Delhi accept writes in both, with multi-cluster routing; a single global load balancer front-ends GKE clusters in each region.
Data Consistency and Routing Decisions in Active-Active
Choosing a write class per entity
Use multi-writer replication for data where the last update winning is acceptable: carts, sessions, preferences, profiles. Use home-region ownership for counters and balances where concurrent writes in two regions would be wrong, such as wallet balances or stock reservations. Keep single-writer for ledgers. In most retail and gaming platforms, 70-85% of request volume can be multi-writer once classified.
Conflict handling
Last-writer-wins is the default in most global tables, so design items as small and independent; store each cart line as its own item rather than one cart document. Where merges matter, use custom conflict resolution (for example Cosmos DB stored procedures) or append-only events. Always record the region and timestamp of each write so the reconciler can explain any divergence.
Capacity headroom
Each region must absorb the other's traffic. With two regions, run each at no more than 50-60% of capacity at peak, or rely on autoscaling that is proven to double capacity within 3-5 minutes. Pre-warm load balancers and reserve capacity for known peaks. Underestimating headroom turns a regional outage into a cascading one in the surviving region.
Routing: latency, geography or cells
Latency-based routing alone causes users to bounce between regions as network conditions shift, increasing conflict risk. Prefer sticky home-region routing by cell or user ID, with latency routing only for unauthenticated traffic. Keep cell count small, typically 4-16 cells across two regions, so evacuation of one cell can be tested independently.
Building Toward the First Region Evacuation
Write-class register and data model changes
Every entity is classified, item granularity is redesigned where needed, and the conflict rule is approved per entity.
Idempotency and regional independence
Mutating APIs gain request keys, synchronous cross-region calls are removed and per-region secrets, queues and caches are set up.
Second region build and data replication
The second regional stack is built from shared code and multi-region data stores are enabled, seeded and lag-monitored.
Cell routing and drain control
Cell assignment, home-region routing and a one-action region drain are implemented and tested with internal users.
Progressive traffic split
Traffic moves from 100/0 to 90/10 and then 50/50 over several weeks, with reconciliation reports reviewed at each step.
Region evacuation drill
One region is drained under live traffic during a normal business period, held for at least two hours, and restored.
What you receive
Active-Active Health and Correctness Measures
| KPI | Typical target |
|---|---|
| Customer-facing error rate during region evacuation | Under 0.5% for the drain window |
| Cross-region replication lag at peak | Under 1-2 seconds for multi-writer data |
| Divergent records found by reconciler after drill | Zero unresolved after 24 hours |
| Duplicate transactions from retries | Zero (idempotency enforced) |
| Time to drain a region | Under 2 minutes from decision |
Active-Active Failure Modes and Their Countermeasures
| Risk | How NTSPL prevents it |
|---|---|
| Duplicate orders or payments after failover retries | Mandatory idempotency keys on mutating APIs, a globally replicated key store and payment gateway integration using the merchant's unique order reference. |
| Hidden synchronous cross-region dependency | Dependency tests block a region's access to the other in pre-production; any request that fails is a defect before go-live. |
| Surviving region overloaded | Headroom is enforced by capacity alarms at 60% peak utilisation, and load-shedding of non-essential features is pre-built. |
| Release breaks both regions at once | Releases roll to one region, bake for a defined period with error budget checks, and only then proceed to the second. |
Active-active vs multi-AZ: do we need two regions if we already span three zones?
Multi-zone deployment protects against a data centre or zone failure and should be the baseline for every production system. It does not protect against a regional control-plane issue, a bad configuration pushed region-wide, a regional networking event or a provider-side incident affecting several zones. Active-active across regions covers those, at roughly double the cost and with real application changes. If your platform loses more than INR 25-50 lakh per few minutes of outage, or you already need two regions for latency, multi-region active-active is justified. Otherwise, multi-zone plus a warm standby in a second region is the better balance.
Key facts: Active Active Resilience
Active Active Resilience in Practice
2 Active Active Resilience scenarios, from E-commerce (home goods and furnishing marketplace) and Online gaming (casual multiplayer, non-real-money), plus related platform case studies.
Home-goods marketplace drains Mumbai at noon and keeps checkout error rate at 0.2%
Casual gaming studio keeps 6 lakh concurrent players online through a regional drain
NBFC moves loan-origination Oracle database to Aurora PostgreSQL and drops EE licences
Microfinance lender moves loan SQL Server to Managed Instance in an 18-minute cutover
Active Active Resilience: Frequently Asked Questions
How much does active-active cost?
Infrastructure typically runs at 80-120% above a single-region deployment, because each region carries spare headroom and data is stored twice. Engineering effort for a platform of 20-60 services is usually a 4-6 month programme. NTSPL limits scope to the customer-facing paths that need it, which keeps total uplift closer to 60-80%.
Can a relational database be active-active?
Conventional single-primary relational databases cannot accept writes in two regions safely. Options are globally distributed SQL databases, partitioning so each region owns a subset of rows, or keeping the relational system as a single writer and moving hot paths to multi-writer stores. Aurora Global Database's write forwarding still sends writes to one primary.
Which Indian region pairs work for active-active?
AWS Mumbai and Hyderabad, Azure Central India and South India, and Google Cloud Mumbai and Delhi. Round-trip latency between these pairs is low enough for asynchronous replication with lag of around a second, while keeping all data in India for DPDP and sectoral rules.
Do we need active-active for every service?
No. Typically only the customer-facing transaction path qualifies: browse, cart, checkout, login or gameplay. Back-office, analytics and batch services stay single-region with backup or warm standby. Mixing patterns is normal and keeps cost proportionate. Over-applying the pattern is the most common reason active-active budgets overrun, so scope is agreed per service before design starts.
How do we test active-active without risking customers?
Start with internal users on a test cell, then drain a small production cell, then a whole region during a normal business period. Each drain is reversible in under two minutes. NTSPL recommends monthly cell drains and a full region evacuation each quarter.
What happens to payments during a region switch?
Payment initiation uses an idempotency key tied to the order reference, so a retry in the other region is recognised. Gateway callbacks are registered to a global hostname reachable in both regions. In-flight payments are reconciled against the gateway's status API after the switch.