Minsheng Bank Data Middle Platform: Cloud‑Native Architecture and Tooling Practices

Amid a "technology + data" driven transformation, Minsheng Bank initiated the design of a data middle platform in 2018, completing it in 2019; the platform’s technical requirements naturally align with cloud‑native concepts, prompting the bank to explore and innovate independently.

The data middle platform, first popularized by Alibaba in 2017, standardizes data collection, processing, and storage across the enterprise, providing a unified data service layer that efficiently supports both business and decision‑making needs, especially critical for large financial institutions.

Minsheng Bank’s implementation follows a microservice + containerization architecture, comprising four core functional systems—Store (data storage), Service (data services), Open (data routing), and Plus (management)—all developed in‑house and built on secure, domestically‑sourced components; the platform now serves over ten business domains, more than one hundred specialized financial scenarios, and handles over ten million daily service calls.

Cloud‑native, introduced around 2013 and formalized by the CNCF in 2015, emphasizes containerization, service mesh, microservices, immutable infrastructure, and declarative APIs; in the bank’s context, cloud‑native equates to microservices + DevOps + continuous delivery + containerization.

The traditional file‑based data delivery model caused four major pain points: excessive storage waste, low transmission efficiency, high manpower costs, and weak governance; these issues map directly to cloud‑native strengths such as heterogeneous storage, service‑oriented data access, automated deployment, and collaborative management.

To address these, Minsheng Bank pursued three layers of innovation: a tool layer that delivers a one‑stop data‑service cloud DevOps workbench, a management layer that introduces scenario‑based financial service governance, and a component layer that establishes a graded approach for heterogeneous storage components.

On the tool side, the bank built a plug‑in development framework generator and a code generator that let developers select required microservice features (service registration, logging, interception, caching, etc.) and storage back‑ends (MySQL, Redis, Gauss, SDB, HBase), automatically producing ready‑to‑deploy code.

It also created a one‑click cloud compilation, deployment, and release toolchain integrated with Docker, enabling end‑to‑end build‑to‑deploy workflows, real‑time progress visibility, and instant version rollback.

Automated source‑level and configuration‑level Change List validation tools provide visual alerts (red for critical failures, yellow for warnings) and halt pipelines when serious issues are detected, ensuring consistent quality across releases.

The platform implements a full‑link service tracing system—leveraging service registration, API keys, trace IDs, logging, and near‑real‑time analytics—to monitor microservice dependencies, latency, and data‑layer access, thereby maintaining operational health.

A lifecycle management tool for heterogeneous storage components balances component capabilities, business needs, and operational levels, supporting data migration scenarios such as retiring MySQL data into SequoiaDB without service disruption.

A visual cache hot‑management tool allows dynamic adjustment of cache TTLs and switches, complemented by KV inspection dashboards and usage analytics to optimize cache performance.

In conclusion, a robust native application must excel both technically and in its supporting management; Minsheng Bank’s experience demonstrates practical solutions to challenges like microservice granularity control and data consistency across diverse storage back‑ends.