When Does a Technical Middle Platform Add Real Value? A Financial Services Case Study

Evolution of the Business System

The architecture progressed through three distinct stages:

Stage 1.0 – Single‑product monolith : A simple buy‑sell service for fund products that directly accessed a relational database.

Stage 2.0 – Monolith supporting multiple products : Transaction volume grew, requiring shared infrastructure components such as Redis, Memcache, message queues (MQ) and an account centre.

Stage 3.0 – Multi‑business line : Different product lines (institutional, retail, high‑end, etc.) were split into separate business units, each with its own front‑, middle‑ and back‑office services.

Prerequisites for Building a Technical Middle Platform

A technical middle platform delivers value only when two preconditions are satisfied:

Verticalized technical organization : Teams are reorganized from functional silos (development, testing, operations) into product‑oriented squads that own the full lifecycle of a service.

Complex, multi‑business lines : A sufficient number of distinct product lines creates a genuine need for reusable services, standardized middleware, and shared data models.

If either condition is missing, the overhead of maintaining a middle platform outweighs its benefits.

Common Problems and Challenges

Bottom‑up decisions ("屁股决定脑袋") : Technology choices are often dictated by senior engineers or legacy decisions, leading to fragmented middleware stacks and duplicated components across teams.

Technical debt : Front‑end teams prioritize rapid delivery, while the middle platform emphasizes stability. The mismatch forces the creation of adapters (e.g., proxy‑based SDKs) to integrate heterogeneous services.

Diverse stakeholder opinions : Leadership preferences can drive inconsistent technology selections, preventing the establishment of unified standards.

Future Direction – Cloud Migration

To reduce headcount pressure and operational costs, the organization plans to migrate standardized services, tooling, and infrastructure to Tencent Cloud. The migration scope includes:

Data‑center resources (compute, storage, networking)

Middle‑platform middleware (Redis, MQ, cache adapters)

Account centre and other shared services

The migration retains clear separation between front‑office, middle‑office, and back‑office layers while leveraging cloud elasticity.

Key Q&A Highlights

Is a middle platform suitable for every enterprise? Only companies with sufficient scale, multiple business lines, and a vertically aligned technical organization that demands extensive reuse should consider it.

How should a startup (< 100 people) approach a middle platform? For small teams with limited product lines, the overhead outweighs benefits; it is advisable to continue using a simpler architecture until the organization grows.