Scaling Consumer‑Finance Databases: Architecture, DevOps, and Future Trends

1. What is Consumer Finance?

Consumer finance is essentially installment shopping, where a user places an order, the system performs risk control, matches funds, generates a bill, and handles repayment. It combines e‑commerce attributes with financial services, requiring high‑concurrency, strong security, and strict consistency.

2. Database Architecture Practice

The team’s database practice spans over two years, evolving through repeated challenges. Initially, two MySQL instances were insufficient for rapid business growth, leading to continuous architectural refinements.

Key problems and solutions include:

Short‑connection pressure: During large‑scale promotions, connection pools were exhausted, causing CPU spikes before MySQL even received requests. The team added a lightweight 360 Atlas proxy to convert short connections to long ones, enabling automatic master‑slave failover and semi‑synchronous replication.

Single‑table bottlenecks: Implemented sharding without middleware, using a local Sharding library that routes queries based on predefined rules (e.g., hundred‑databases‑ten‑tables, yearly‑monthly, yearly‑daily). This approach keeps calls local and fast.

Configuration inconsistency: Moved from scattered config files and hard‑coded values to a centralized configuration center that automatically pushes updates to applications, eliminating manual restarts.

Resource isolation in mixed‑deployment environments: Adopted cgroups for lightweight CPU, memory, I/O, and network isolation, allowing dozens of instances per machine while briefly pausing services during reconfiguration.

Cache scaling: Deployed Redis for read‑through caching, using a middleware‑less sharding solution. Horizontal scaling is achieved by adding new shards, syncing data with Redis‑port, and switching proxies with minimal downtime.

Cache‑DB consistency: For read‑heavy, write‑light workloads, MySQL binlogs are captured by Otter, pushed to MQ, and consumed to update Redis, guaranteeing eventual consistency without extra reconciliation. For read‑write‑heavy scenarios, writes go to both Redis and MQ, with asynchronous MySQL updates to reduce load.

3. Database DevOps Practice

The team defines DevOps as leveraging platforms to improve efficiency across development, operations, and quality. Their transformation began by addressing a painful DML/DDL change workflow, automating it with open‑source tools and custom scripts.

Key components of their DevOps platform include:

Front‑end built with a low‑code solution (BlueKing Magic Box) for better usability.

Back‑end services using Django (alternatives: Flask, Tornado).

Integration of Inception for SQL review with custom rules.

Deployment via Nginx + uWSGI.

The platform now offers SQL query, table lookup, slow‑query view, private‑cloud MySQL, instance details, and daily inspection features, reducing manual effort for dozens of daily DML/DDL requests.

4. Outlook

Looking ahead, the team is exploring NewSQL solutions such as Google Spanner and TiDB, which combine NoSQL scalability with ACID guarantees. They also see AI as a critical next step: tools like OtterTune for automatic DB tuning, AIOps for anomaly detection, capacity prediction, and fault forecasting, all built on big‑data and machine‑learning techniques.