Xinye Technology's OceanBase Practice: From Risk-Control Core to an AI Data Foundation

Xinye Technology (NYSE: FINV) is a fintech group whose risk-control systems support high-frequency, complex financial transactions across multiple regions. For these systems, data consistency, high availability, and online elasticity are operational requirements. Its database modernization began with the limits of sharded MySQL: growing data volumes, cross-shard complexity, and an increasing operational burden. The team sought a distributed database platform that could simplify application development, improve resilience, and support future AI-oriented workloads.

The challenge: sharded MySQL at risk-control scale

Sharding splits one logical database across many MySQL instances. It works early on, but as the business grows, the cracks show:

• Routing complexity — application code must know which shard holds which data, and every new query pattern risks an expensive cross-shard join.
• Cross-shard transactions — operations that span shards need distributed coordination, adding latency and failure modes a single-node database never exposed.
• Capacity planning pressure — hot shards fill up while others sit idle; rebalancing data becomes a project, not a routine task.
• Operational burden — backups, failover, schema changes, and incident response multiply with every shard.

For latency-sensitive risk-control services, these constraints became increasingly difficult to manage. The team needed a distributed database that could absorb growth without transferring sharding complexity back to application code.

Why Xinye Technology chose OceanBase

Xinye evaluated distributed database options, including TiDB, before selecting OceanBase. The practice report identifies three principal considerations:

1. Lower storage cost — OceanBase’s LSM-Tree storage engine and compression capabilities reduced the storage footprint of archived historical data compared with the prior MySQL deployment.
2. Online scale-out — when archive-cluster resources were insufficient, the team could add OBServer nodes instead of undertaking a manual re-sharding project.
3. High availability for financial workloads — Xinye required strong consistency and data-loss protection during failover; OceanBase’s high-availability architecture met its evaluation requirements.

OceanBase also offered a path to retire the sharding middleware layer and let developers write ordinary SQL again, while still meeting the latency and consistency requirements of real-time risk scoring.

Migration approach: OMA assessment and OMS execution

Migration was treated as an engineering program rather than a one-time database switch. The team used OceanBase tooling across assessment, migration, validation, and rollback preparation:

• OMA (OceanBase Migration Assessment) — assessed SQL compatibility and supported production-traffic capture and replay to identify performance and lock-contention risks before cutover.
• OMS (OceanBase Migration Service) — supported schema migration, full and incremental synchronization, and reverse synchronization to keep a rollback path available during migration.

The rollout followed four principles:

1. Validate representative workloads — test compatibility, partitioning, indexes, and transaction patterns against production-like traffic before each cutover.
2. Use controlled cutover paths — migrate with OMS during low-traffic periods or use application-controlled dual writes and gradual traffic rollout.
3. Keep rollback ready — reverse synchronization and traffic controls allow rapid restoration if monitoring detects an issue.
4. Share operational ownership — DBAs and application teams used common procedures so OceanBase became part of the normal delivery workflow.

The goal was not merely to move data. It was to reduce dependence on the sharding middleware layer, simplify delivery, and centralize operational visibility.

For core risk-control services, the team standardized on OBProxy as the database access layer. OBProxy provides routing, load balancing, and failover handling, reducing the need for shard-aware connection logic in applications. The practice report also notes that version compatibility and query-plan behavior must be validated carefully, particularly for large analytical extraction workloads.

High availability, lower cost, and multitenancy on OceanBase

Once core workloads landed on OceanBase, the practice report highlighted several concrete gains:

• LSM-Tree storage compression — for the reported historical-data workload, storage fell from 89 TB to 29 TB, a 67% reduction. This is a workload-specific result, not a general compression guarantee.
• Same-city dual-active operations with a standby tenant — a physically synchronized standby tenant provides tenant-level disaster recovery. The reported design targets RPO = 0 and second-level takeover; the achieved outcome depends on the selected replication mode and operating conditions.
• “Switching the Huangpu River” drills — the team conducts recurring same-city dual-active exercises to practice role switching, traffic control, and rollback across data centers.
• Resource pooling and multitenancy — the reported deployment improved overall resource utilization by roughly 40% and shortened new-business-node deployment cycles by about 90%. These are Xinye-specific operational results.

The diagram shows a primary tenant in one data center and a physically synchronized standby tenant in another. During a “Huangpu River” drill, the team deliberately switches roles and validates application reconnection, traffic control, and rollback procedures.

Multitenancy allows risk control, reporting, and experimental workloads to share a cluster while remaining isolated at the tenant level. Xinye allocates tenants from a shared resource pool and adjusts CPU, memory, and storage as demand changes. CPU binding and IOPS limits are used to reduce interference between workloads.

Automation connects deployment, monitoring, diagnosis, and daily operations. A production incident involving SQL plan binding reinforced a key operating lesson: management-console status must be verified against database metadata, and emergency controls such as rapid session termination need to be part of the response procedure.

Next steps: AIOps and an OceanBase AI data foundation

Database modernization does not end with migration. Xinye’s roadmap moves from manual response toward assisted operations and an AI-ready data layer:

• AIOps — use observability data and automation to detect anomalies, assist root-cause analysis, and reduce mean time to recovery. Xinye’s target operating model retains DBA confirmation before automated remediation.
• Archive governance — automate the tiering, retention, and purging of historical risk data with partition-based lifecycle management and region-specific storage choices where data-residency requirements apply.
• Integrated vector foundation — evaluate OceanBase vector capabilities for semantic search and AI applications alongside transactional workloads, including risk-control use cases such as identifying related fraud patterns.

The reported direction combines a distributed OceanBase data foundation with high-availability drills, automated governance, and disciplined operations. It is intended to support both latency-sensitive risk-control transactions and future AI workloads, while keeping claims about performance and automation scoped to Xinye’s specific environment and roadmap.