How to Handle 30,000 Writes per Second with Oracle, Java, and Spring

Sharding Is Our Solution

More than a decade ago I participated in a sharding migration for an e‑commerce system that used MySQL rather than Oracle. The direct reason for sharding was the write TPS limit of a single MySQL instance, roughly 12,000 TPS. At the time the peak order‑placement traffic during a big promotion was 2,000 TPS, which the single instance could still handle, but projected growth would soon hit the ceiling.

The architects decided to shard and planned 168 MySQL instances to support ten years of growth. Assuming 12,000 write TPS per instance, the 168 databases left ample headroom. The project was a large‑scale technical initiative, took over six months, and the first three rollouts failed; the fourth succeeded after addressing double‑read/write, data‑quality checks, and consistency verification. Any error in the order‑to‑settlement‑to‑inventory flow caused production failures that were hard to fix.

By 2026 the same 168 databases are still running and handling the workload. I have no direct data on Oracle’s single‑instance write capacity, but a general rule holds: when write concurrency is too high, you must alleviate it, and sharding is one path.

Why the Main Payment Chain Should Not Use Queue‑Based Peak Shaving

Some teams suggest using MQ to smooth spikes. I do not recommend this for core order‑payment systems.

Creating an order involves inventory deduction and coupon reduction. Users need an immediate result, and inventory and coupon states must stay consistent with business logic. Queuing the request and persisting asynchronously lengthens user‑side latency, introduces more intermediate states, and makes troubleshooting harder, harming user experience.

MQ is better suited for decoupling downstream notifications, not for absorbing write pressure on the core transaction path.

Distributed Databases Are Worth Researching

The 168 physical shards remain effective, but the solution is over ten years old. Cloud‑native distributed databases offer another route: they embed sharding, routing, and partial distributed transaction support into the product.

Both approaches solve the same problem and are not mutually exclusive. For a new system built in 2026, I would first evaluate whether a distributed database can reduce the operational complexity of maintaining 168 instances, rather than automatically replicating the same sharding scheme. If an existing sharded setup is stable, the benefits of migration must be weighed against the one‑off migration cost.

Dimension          | Self‑built N‑shard   | PolarDB‑X / TiDB / OceanBase
-------------------|----------------------|-----------------------------------
Write scaling      | Add instances & change routing | Add data nodes or Regions, elastic scaling by provider
Cross‑shard txn   | Business avoidance or middleware | Built‑in distributed txn, with latency & hotspot cost
Index writes      | Single‑instance index, MySQL‑like behavior | Global index write amplification, watch local index & shard key
Operations         | Maintain N separate instances | Cluster‑level ops, rely on vendor or cloud platform
Migration cost    | Completed shards become sunk cost | Switching still a large‑scale project

The following points are taken from product homepages or official docs; they are not my own test results. Selection still requires a proof‑of‑concept with realistic schemas and traffic.

OceanBase : The official site says it targets high‑concurrency transaction scenarios such as finance and telecom, claims a TPC‑C record, and notes long‑term use in Ant Group’s core transaction system and Double‑11 events. It emphasizes MySQL and Oracle compatibility and high‑availability for write‑intensive, strongly consistent workloads. Benchmark numbers are for reference only.

TiDB : TiDB positions itself as an HTAP (Hybrid Transactional/Analytical Processing) distributed database, compatible with the MySQL protocol and ecosystem. It provides cross‑data‑center deployment topologies and multi‑AZ solutions for disaster recovery, suitable for workloads needing both transactions and real‑time analytics.

PolarDB‑X : Official docs describe it as a shared‑nothing distributed database for ultra‑high write concurrency and massive storage, originally designed for Alibaba’s Double‑11 core transaction expansion. PolarDB‑X differs from PolarDB MySQL, which uses shared storage; PolarDB‑X implements sharding and horizontal write scaling.

GoldenDB : ZTE’s GoldenDB financial application guide states it targets core financial systems. Public cases include deployments by China Mobile, China Unicom, and several banks, useful for financial‑sector selection but still requires a custom POC.

Public Practices from Major Chinese Tech Companies

Below are links to publicly available articles, organized by company. The peak values and shard scales are specific to the cited years and scenarios and should not be directly transplanted.

Alibaba/Ant Group

Financial‑grade unitized distributed architecture design and practice (Alibaba Cloud Developer Community): RZone/GZone/CZone unit division, three‑region five‑center topology, five‑replica sharding, and how units achieve isolation and multi‑active‑active deployment.

OceanBase 2.0 makes million‑level payments possible? (Alibaba Cloud Developer Community): From hundreds of databases/tables to UID‑based partitioning, illustrating how to further split when write bottlenecks appear.

Ant Finance 11.11: Technical architecture and practice of Alipay and Ant Huabei (InfoQ): LDC logical data centers, blue‑green releases, full‑link stress testing, reporting ~40,000 payments per second in a specific year’s test.

Behind Alipay: OceanBase ten‑year journey (InfoQ): Timeline of migrating transaction and payment databases to OceanBase, with public peak figures from Double‑11 events.

Meituan

Horizontal sharding and table splitting

Multi‑dimensional redundant storage for queries

Dual‑write + reconciliation migration

Key articles:

Public article on Dazhong Dianping order system sharding (Meituan): 32×32 sharding, UserId/ShopId split, order‑id routing rules, and a three‑stage dual‑write migration (reconciliation, read‑only switch, stop writing to old shards).

Evolution of Meituan Waimai order center: After a single‑instance write limit is reached, data is duplicated by order‑ID, user‑ID, and shop‑ID, with an application‑level sharding plugin to avoid scattering shard logic across business code.

JD.com

Apache ShardingSphere case study co‑authored by the JD Baitiao team: billions of rows, nearly ten thousand data nodes, hash sharding to avoid hotspots, and an approximately four‑week cut‑over process. The scenario is credit‑payment (Baitiao), not the main e‑commerce order DB, but the sharding methodology is comparable.

ByteDance

Unitized architecture practice in ByteDance (InfoQ): Douyin, Douyin e‑commerce, and Douyin Payment adopt cross‑region unitization with strong consistency requirements.

https://mp.weixin.qq.com/s?__biz=MzI1MzYzMjE0MQ==∣=2247493763&idx=1&sn=19390055f5b7b1186f830fa0579306ea&scene=21#wechat_redirect: veDB’s compute‑storage separation, stateless elastic compute scaling, and multi‑replica strong consistency, representing a different technical route.

Conclusion

For 30,000 payment requests per second, write pressure must be mitigated. Our historical solution used 168 MySQL instances to shard writes, which still runs today; the main order chain should not rely on MQ for peak shaving. In 2026, distributed databases such as PolarDB‑X, TiDB, and OceanBase are worth evaluating, but a proof‑of‑concept must use realistic schemas and traffic rather than vendor‑published peak numbers. Public articles from Alibaba, Meituan, JD.com, and ByteDance provide concrete references for further study.