핵심 요약
- Four scenarios, one mechanism: disaster recovery, multi-region scale, real-time analytics, and AI agent state all run on the same replication techniques, tuned differently.
- Your recovery point and recovery time objectives decide the tuning. A bank protecting a ledger and a loyalty program updating a recommendation optimize for opposite things.
- MNC Bank, Flipkart, Rakuten, and Kimi each sit at a different point on the same consistency-versus-latency tradeoff.
- None of the four needed a different database. They needed different settings on the same one.
If you have never tested your disaster recovery plan against a real regional outage, you have a guess, not a plan.. The same is true for a multi-region deployment that has never served traffic during a network partition, or an AI agent platform that has never had to recover a session after a node failure. Data replication strategies only prove themselves under exactly those conditions, which is why the most useful way to evaluate one is to see how a real system used it, not just to read a definition.
This guide walks through four scenarios, each grounded in how a real company solved it: disaster recovery and high availability, multi-region scale, real-time analytics, and AI agent state. All four draw on the same small set of replication techniques, tuned differently.
If you still need the underlying technique definitions, synchronous, asynchronous, snapshot, transactional, merge, and log-based, and how 티DB implements them with Raft, start with our guide to data replication techniques. This article assumes that groundwork and focuses on application.
What Are Data Replication Strategies Used For?
Data replication strategies apply a specific replication technique to a real business problem: keeping a bank’s ledger available during an outage, serving a global user base from a nearby region, keeping a dashboard current without slowing down production, or keeping an AI agent’s session state intact across restarts. This guide covers four of the most common: disaster recovery and high availability, multi-region scale, real-time analytics, and AI agent state.
The technique itself, synchronous, asynchronous, log-based, and so on, is only half the decision. The other half is matching that technique to what the business actually cannot afford to lose or wait for. A bank and a loyalty program both use replication, but they tune it for opposite priorities: one optimizes for never losing a confirmed transaction, the other optimizes for keeping recommendations current without adding latency to every write. That is why the same underlying mechanism shows up under four very different requirements below.
Disaster Recovery and High Availability
Financial institutions cannot treat downtime as an acceptable cost. A banking system that goes dark during a regional outage is not just an inconvenience: it can mean failed transactions, regulatory scrutiny, and customer trust that does not come back easily. That combination pushes the recovery point objective (RPO) toward zero and the recovery time objective (RTO) toward seconds, the profile that favors synchronous or transactional replication paired with automatic failover.
MNC Bank runs on TiDB for exactly this reason. Its workload depends on strong consistency and fast recovery from node failures, which TiDB provides through Raft groups that commit a write only after a majority of replicas confirm it, with automatic leader election when a node goes down. That matters most at the moment that would otherwise page an on-call engineer: the cluster resolves the failover itself in seconds, rather than leaving someone to promote a replica by hand and hope the failover did not lose a committed transaction.
TiDB backs this further with its disaster recovery solution, which layers snapshot backups on top of the same Raft log replication, so recovery does not depend on a separate backup pipeline running on its own schedule. For a bank, that distinction is not academic: a nightly snapshot backup means a worst-case loss window of up to 24 hours, while continuous Raft log replication means the worst case is measured in the seconds it takes a Region to fail over. The result is a system where a single node failure does not turn into a customer-facing outage, and where recovery time is a property of the architecture rather than a hope that the last backup was recent enough.
Multi-Region and Global Scale
Serving users across a large geography means choosing between synchronous consistency and acceptable latency, and for most consumer-scale platforms, latency wins. A synchronous write that has to wait for confirmation from a replica on another continent adds hundreds of milliseconds to every transaction, which shows up directly as a slower application. At consumer scale, that latency compounds: a checkout flow with several sequential writes can turn a 200 ms round trip into a multi-second wait before the user sees a confirmation.
Flipkart uses TiDB to manage database complexity at a scale where manual sharding and multiple specialized data stores had become the bottleneck. Before consolidating onto a distributed SQL database, scaling meant coordinating schema changes and replication settings across several separate systems, each with its own operational overhead. Asynchronous and log-based replication are what let a distributed SQL database keep regional replicas current without forcing every write through a cross-region round trip, which is what makes horizontal scale-out practical for a platform serving traffic across a large, geographically spread user base. The tradeoff is a small, bounded window where a regional replica can lag slightly behind the primary, which is an acceptable cost for most reads and a deliberate choice rather than an accident of the architecture.
Real-Time Analytics and Personalization
A loyalty or personalization system working off yesterday’s data makes worse recommendations than one working off this morning’s data, and the gap only grows as the delay grows. Building a separate batch pipeline to keep an analytics store current is one way to close that gap, but it adds a system to maintain, a schedule to manage, and a delay built into the pipeline itself: even an hourly batch job means every recommendation is, on average, 30 minutes stale.
Rakuten runs its loyalty program on distributed SQL for this reason. Log-based replication streams changes directly from the transaction log to the systems that need them, which keeps personalization and loyalty calculations working from current data without a batch job standing between production and analytics. A purchase, a redeemed point, or a tier upgrade is reflected in the next recommendation almost immediately, rather than after the next scheduled sync. That responsiveness is what separates a loyalty program that feels current from one that visibly lags behind what the customer just did.
AI Agent and Application State
An AI agent that loses its session state after a node restart has to start over, which is a worse experience than a web application that simply reloads a page, because the agent may be partway through a multi-step task involving several tool calls and intermediate decisions. Agents that persist state across sessions depend on the same consistency guarantees as any other transactional workload: a write needs to actually be durable before the agent can trust that it happened and move on to the next step.
Kimi, an agent hosting platform, runs on TiDB Cloud for this reason. The same Raft-based replication that keeps a bank’s ledger consistent keeps an agent’s state consistent: a write only commits once a majority of replicas confirm it, so a node failure mid-task does not silently drop a step the agent already believed had completed. That matters more as agent workloads take on longer-running, multi-step tasks rather than single-turn requests, since a lost write further into a task costs more rework than one near the start.
Comparing the Four Strategies
The four scenarios above use overlapping techniques but land on very different recovery targets. This table summarizes where each one sits.
| Scenario | Primary Technique | Example | RPO/RTO Profile |
|---|---|---|---|
| Disaster recovery and high availability | Synchronous or transactional, with automatic failover | MNC Bank | Near-zero RPO, single-digit-second RTO |
| Multi-region and global scale | Asynchronous or log-based | Flipkart | Small bounded lag acceptable, RTO less critical per region |
| Real-time analytics and personalization | Log-based (CDC) | Rakuten | Seconds of lag acceptable, no failover requirement on the analytics path |
| AI agent and application state | Synchronous or transactional, per-write durability | Kimi | Near-zero RPO per committed step, RTO scoped to session continuity |
How TiDB Supports These Scenarios
All four scenarios above run on the same underlying mechanism, just tuned differently. 티DB‘s storage engine, TiKV, replicates data through Raft consensus groups, and a write only commits once a majority of replicas confirm it. That mechanism is what gives disaster recovery and financial workloads the consistency they need, while TiCDC’s real-time change data capture is what makes the analytics and multi-region scenarios practical without a separate batch pipeline. The difference between MNC Bank’s use case and Flipkart’s is not a different database. It is a different point on the same consistency-versus-latency tradeoff, configured through the same replication mechanism.
For the full mechanism, including how Raft groups, the Placement Driver, and TiCDC fit together, and a framework for matching a technique to your own recovery point and recovery time objectives, see PingCAP’s guide to data replication techniques.
Start From What You Cannot Afford to Lose
Every scenario above starts from the same two questions: how much data can you afford to lose, and how long can you tolerate being down. Once those are set, the technique and the architecture mostly choose themselves. MNC Bank, Flipkart, Rakuten, and Kimi answer those two questions differently, which is exactly why they end up tuning the same replication mechanism in four different directions rather than reaching for four different databases.
To see how TiDB’s Raft-based replication would handle your own workload, start with TiDB Cloud Starter, a free tier that runs the same replication model behind all four examples above.
Data Replication Strategy FAQs
What is a Data Replication Strategy?
A data replication strategy applies a specific replication technique to a real business requirement. The technique, whether synchronous, asynchronous, log-based, or another, is only half of it. The strategy is the pairing of that technique with a recovery point objective and recovery time objective the business can actually live with. The same mechanism becomes a different strategy depending on whether you are protecting a ledger, serving a global user base, or feeding a dashboard.
How Do Companies Use Data Replication for Disaster Recovery?
The common pattern pairs synchronous or transactional replication with automatic failover. Synchronous or transactional replication keeps the recovery point objective near zero, so no confirmed transaction is lost, and automatic failover keeps the recovery time objective low, so recovery completes in seconds rather than hours. MNC Bank runs this pattern on TiDB, where Raft-based replication commits a write only after a majority of replicas confirm it and the cluster elects a new leader on its own when a node fails.
Which Replication Strategy Works Best for Multi-Region Applications?
Asynchronous or log-based replication usually wins, because it avoids forcing every write through a cross-region round trip. The tradeoff is a small consistency window where a regional replica lags behind the primary, which most reads tolerate comfortably. Synchronous replication is typically reserved for writes within a single region, where the confirmation round trip costs microseconds rather than hundreds of milliseconds. Flipkart uses this split to scale database operations across a geographically spread user base.
Do AI Agent Platforms Need Data Replication?
Yes. An agent that persists state across sessions needs the same durability guarantees as any transactional workload, because a lost write means the agent restarts a multi-step task from scratch. The cost of that restart grows the further into a task the failure happens. Kimi runs its agent hosting platform on TiDB Cloud for this reason, using the same Raft-based consistency model that protects financial data to protect agent state.
What is the Difference Between a Replication Strategy and a Replication Technique?
A technique is the mechanism: how and when copies of data move between nodes. A strategy is the decision about which technique to apply to a given workload, driven by how much data the business can afford to lose and how long it can afford to be down. Two companies can run the identical technique and still have different strategies, because they have set different recovery targets. The techniques themselves are covered in full in the companion guide.