Ant Group moved Alipay's core transaction data off a commercial relational database onto OceanBase, its own distributed database, beginning with a 1% slice in 2014 and reaching full replacement in 2019. What risk control is that ramp actually providing, and where would copying it be a mistake?

The situation they were in

Alipay's transaction path is a payments system: a wrong answer is a financial error, not a slow page. OceanBase's own account describes a project begun in 2010, a team moved to Ant Group in 2014 to replace the commercial database under Alipay, a first production trial at 1% of the transaction database, then 10%, and full replacement by 2019. Alibaba's Double 11 event in 2020 recorded a peak of about 583,000 orders created per second, which is the scale the replacement eventually had to carry.

The headline is not the database. It is that a replacement of the most critical store in the company took roughly five years and was never once a cutover.

What the ramp is actually controlling

A percentage ramp is often described as "reducing blast radius", which is true and is the least interesting part. Its real function is different:

• It buys production evidence that no test environment can produce. The behaviours that matter — contention under real key distributions, the long tail of transaction shapes, operational behaviour during failover — appear only under real traffic, and 1% of a payments workload is still an enormous sample.
• It forces the coexistence machinery to exist early. At 1% you must already have routing, reconciliation between the two stores, comparison of results and a rollback path. Those are exactly the components that a big-bang plan defers until they are expensive to add.
• It converts an irreversible decision into a series of reversible ones. At each step the question is not "is this right" but "what did the previous step tell us", and the step size is chosen so that being wrong is survivable.
• It gives the organisation a legitimate way to stop. A programme that can only succeed or fail has no third option; a ramp can be paused at 10% for a year while a defect class is understood.

What it cost them

Years of engineering on infrastructure that produced no customer-visible feature, a long period operating two stores with the reconciliation burden that implies, and the organisational patience to hold a technical programme through several planning cycles. Most of that cost is not technical, and it is the part that fails first elsewhere.

Where copying it would be a mistake

Do not copy the build. Writing a distributed relational database is justified by a combination almost nobody has: a workload at the top of the world's scale distribution, a regulatory or commercial reason the available options do not fit, and a decade of funding. A team of forty choosing to build its own store because the managed one is "limiting" is making a different and much worse decision.

Copy the ramp instead. The transferable lesson is the sequencing — routing, comparison and rollback before the first percent, then step sizes chosen so that each one is recoverable — and it applies equally to a migration between two managed databases that takes six weeks.

When this is the wrong answer

A ramp needs a routing point. If the system has no place where traffic can be split — a single batch job, a desktop application talking straight to a database — the honest answer is to create that seam first or to accept a cutover, not to pretend a percentage ramp is available. Inventing the seam is usually the cheaper of the two and is the step most programmes skip.