For a bank, selecting a distributed database does not always mean replacing every existing core system at once. A new digital business may need a different delivery model while established services continue operating. The difficult question is how those environments coexist without leaving business responsibilities unclear.
Bank of Nanjing’s published experience offers a historical example of that narrower transition. It is useful for a bank considering a separate internet-finance core, provided the account is read within its stated scope. It should not be retold as evidence that the bank replaced every traditional core workload.
Preserve the scope of the historical project
OceanBase’s supplied Chinese case collection describes a dual-mode principle established in early 2017: retain the traditional core while building a distributed platform for internet finance. The distinction between those systems is central to understanding the project.
Alibaba Cloud’s SOFAStack customer account also describes a new internet-finance core using SOFAStack, OceanBase, and a big-data platform. It explicitly discusses integration with traditional core banking systems. These are supplier accounts of an implementation, rather than an independent evaluation of all banking database options.
For another buyer, the relevant precedent is coexistence with a defined new-business scope. It is not a universal instruction to build a second core, nor confirmation of the bank’s current architecture.
Define what makes the new core a separate responsibility
A second core needs more definition than a separate deployment diagram. Specify which products and operations it owns, which records remain authoritative elsewhere, and how a customer request crosses the boundary. Without those decisions, the same business obligation can appear to have two owners or none.
Consider an illustrative digital lending service beside established account services. The design must identify who approves a lending action, where the resulting obligation is recorded, and which system supplies the customer-facing status. Those responsibilities should be settled before comparing database configurations.
The new environment may also develop at a different pace. Faster release cycles are useful only when changes preserve the agreement between the two sides. A revised product rule must not silently change how an established service interprets a request.
Evaluate integration as a continuing service
Integration is not finished when the first successful request travels between systems. Banks also need to understand delayed responses, rejected requests, business corrections, and periods when one side cannot complete its part. These situations define the operating burden of coexistence.
Ask teams to explain a small set of complete journeys. Follow an accepted operation from customer request through both environments, then examine a request that remains unresolved. The objective is a consistent business explanation, not merely evidence that a connection exists.
Keep the integration responsibility visible in the selection process.
| Boundary question | Evidence worth reviewing | Decision it supports |
|---|---|---|
| Which core owns this operation? | Product and responsibility map | Prevent conflicting business authority |
| What does the other core need? | Agreed request and result meanings | Preserve the service relationship |
| What happens during a delay? | Customer-status and investigation example | Handle incomplete work coherently |
| Who approves a boundary change? | Joint change ownership | Maintain coexistence over time |
This is a proposed evaluation framework. It does not claim to describe Bank of Nanjing’s internal procedures or prescribe a regulatory design.
Compare database routes within that boundary
OceanBase deserves consideration when the proposed internet-finance service needs distributed relational processing and the organization is prepared to operate the surrounding architecture. The historical case supplies a relevant implementation reference. It does not establish application compatibility, support coverage, or resilience for another bank’s deployment.
The comparison should also include the retained platform where appropriate. If existing Oracle or SQL Server services already meet a particular business requirement, moving that responsibility needs its own justification. The second-core project should not become an unexamined reason to relocate unrelated workloads.
Other shortlisted distributed databases should face the same service examples, integration responsibilities, and operating questions. Brand familiarity and a prominent customer reference are useful starting points for investigation; neither substitutes for evidence about the buyer’s actual boundary.
Do not score the database and integration layers as if one could automatically compensate for the other. A strong database result does not resolve conflicting business authority. A polished interface does not establish the underlying database’s behavior under the intended load.
Make coexistence an explicit management choice
A second core can create room for a new business model while reducing the scope of an immediate replacement. It also creates a relationship that must be maintained. The sponsor should understand both sides of that tradeoff before approving the program.
The decision record should explain why this business belongs in the new core, what remains in the established environment, and how that boundary can change later. Expansion should follow evidence about another defined responsibility, rather than the assumption that the first launch approved every subsequent migration.
Bank of Nanjing’s account is most informative when used this way: as an example of a bounded architectural transition involving OceanBase and a wider platform. A buyer can learn from the route while retaining responsibility for its own product scope, integration model, and operating acceptance.
This article is based on documented sources and editorial analysis. Proposed evaluation examples are not independently measured benchmark results.