R&D Management 16 min read

The Evolution, Practices, and Pitfalls of Mid‑Platform (Zhongtai) Architecture in Large Tech Companies

This article traces the origin of the mid‑platform concept, examines how major Chinese tech giants implement and classify their mid‑platforms, explains the distinction between front‑end, back‑end, and mid‑platform layers, and outlines common pitfalls and practical challenges in building and operating such platforms.

Architects' Tech Alliance
Architects' Tech Alliance
Architects' Tech Alliance
The Evolution, Practices, and Pitfalls of Mid‑Platform (Zhongtai) Architecture in Large Tech Companies

1. Origin of the Mid‑Platform

In 2009 Alibaba’s shared‑business division was created, later inheriting the mid‑platform responsibility. In 2015 a visit by Alibaba executives to Finland’s Supercell—a small, fast‑moving game studio—highlighted the need for a flexible, modular architecture, prompting the “big mid‑platform, small front‑end” restructuring. Subsequent years saw Didi, JD, iQiyi, Baidu, ByteDance, Zhihu, and Tencent publicly adopt or discuss mid‑platform strategies.

2. Major Companies’ Mid‑Platforms

Alibaba : Uses a “big middle platform, small front‑end” model to standardize technology and accelerate delivery.

Tencent : Aligns its technology committee with Alibaba’s mid‑platform division, focusing on technology standardization to efficiently provide capabilities to customers.

Baidu : Builds reusable mid‑platform capabilities, offering both generic and customized services to reduce business‑logic duplication.

Mi : Pursues a three‑year business‑mid‑platform strategy covering enterprise strategy, business execution, support, and data governance.

Didi : Constructs a business‑mid‑platform based on five‑fold “‑ization”: service‑oriented, asynchronous, configurable, plug‑in, and data‑driven.

JD : Develops a shared, standardized data mid‑platform to turn massive historical data into valuable assets for intelligent decision‑making.

NetEase : Differentiates between “fat”, “standard”, and “platform” mid‑platforms based on the degree of integration with business teams.

Yonyou : Evolves its IUAP platform into a “3+2+1” architecture: three core mid‑platforms, two major services, and one unified development platform for all customers.

Zhihu : Operates a “big mid‑platform, small front‑end” model where three front‑end business units (community, commercialization, membership) share a common technology team.

3. Front‑End, Back‑End, Front‑Stage, Mid‑Stage, Back‑Stage Definitions

Front‑end refers to HTML/CSS/JS code that renders UI. Back‑end covers business‑logic code such as beans, DAOs, controllers, and services. Front‑stage combines front‑end and back‑end to form user‑facing systems (websites, apps, WeChat). Mid‑stage (mid‑platform) sits between front‑stage and back‑stage, abstracting common business logic to reduce duplication and improve stability. Back‑stage consists of core resource systems (finance, product, CRM, logistics) and underlying infrastructure.

4. Types of Mid‑Platforms

Data Mid‑Platform: Collects, processes, stores, and standardizes massive data to provide unified datasets for downstream consumption.

Technical Mid‑Platform: Extends a technical platform with business‑specific capabilities.

Business Mid‑Platform: Focuses on online‑centric business functions, especially in the OL‑DI era where core services are internet‑based.

5. Common Pitfalls

Organizational errors: Over‑staffing versus agile small‑team efficiency.

Poor business decomposition leading to unclear responsibilities.

Misuse of micro‑services: Over‑splitting creates excessive maintenance overhead.

Over‑design: Building architecture for hypothetical problems instead of current needs.

Front‑stage trial‑and‑error without proper governance.

Unclear benefit allocation among teams sharing mid‑platform components.

Rigid copying of other companies’ architectures without adapting to local context.

Choosing unsuitable leadership for the mid‑platform team.

6. Typical Scenes During Mid‑Platform Construction

Early survival challenges: Mid‑platform teams must satisfy multiple front‑ends, often lacking authority.

Personnel changes: Re‑allocation or layoffs, especially during industry downturns.

Sequential building: Companies often start with data or technical mid‑platforms before tackling business mid‑platforms due to lower organizational impact.

Potential disappearance: Without strong collaboration with front‑ and back‑stages, mid‑platforms may be dissolved.

Talent sourcing: Mix of internal transfers, external hiring, and internal training.

Organizational adjustment timing: Deciding whether to restructure first or build the platform first.

7. Promotional Section (Non‑Academic)

The remainder of the source contains a Spring Festival promotion for a bundled technical ebook collection, listing titles such as “RDMA Principles”, “Container Architecture”, “Kubernetes Summary”, etc., with pricing details and a QR‑code reminder.

Software ArchitectureR&D managementdata platformenterprisemid-platform
Architects' Tech Alliance
Written by

Architects' Tech Alliance

Sharing project experiences, insights into cutting-edge architectures, focusing on cloud computing, microservices, big data, hyper-convergence, storage, data protection, artificial intelligence, industry practices and solutions.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.