Design and Evolution of Meituan's Distributed Code Hosting Platform

Meituan's self‑built code hosting platform, named Code , provides Git version control, branch management, code review and integrates with many internal development tools. After three years of construction it manages tens of thousands of repositories and processes tens of millions of Git‑related requests per day. This article describes the challenges encountered during its evolution and the practical solutions adopted.

Development history can be divided into three stages:

1. Single‑machine deployment : The initial system was a simple web application running on a single server. Because Git stores data as files, high‑IO disks were critical.

2. Multi‑machine deployment : Rapid growth of users and CI pipelines exposed two bottlenecks – storage (SSD usage reached 80% capacity) and load (CPU/IO utilization >95%). A read‑write separation architecture was introduced, routing HTTP and SSH requests to dedicated master and slave nodes, effectively doubling read throughput.

3. Self‑developed distributed platform : To achieve high availability and horizontal scalability, Meituan adopted an application‑layer sharding architecture with multi‑active replication. This design satisfies both scalability and availability requirements.

Key architectural components include:

Proxy modules : SSH Proxy (built on go‑crypto) and HTTP Proxy (built on Go‑Gin) handle request routing and traffic control.

Routing module (Shard service) : Maintains the mapping between repositories and shards, decides read/write routing based on version numbers, and implements read‑repair logic.

Application module : Provides Git‑related business logic, code review, and event notification.

Storage module : Consists of Git Server (based on GitLab components), Replication Manager, Code Core, Git Core, and Git Command Factory. All services communicate via gRPC.

Git Cluster : A three‑node cluster per shard with multi‑active replication, ensuring strong consistency from the user’s perspective.

Scalability goals focus on horizontal expansion of compute and storage resources. The routing layer uses version‑based arbitration (N=3, R=W=2) and read‑repair to keep data consistent across nodes.

Availability goals address data safety. The system employs multi‑active replication (three copies per shard), cross‑data‑center backup (at least two data centers per shard), hot backup with near‑zero latency, and a comprehensive inspection service that monitors refs and version data.

Data compression is applied to refs logs: consecutive logs such as

main -> a

main -> e

main -> f

are compressed into a single entry main -> f while preserving the same replay result.

The inspection service operates in three modes (point, full, scheduled) and checks both refs consistency and version drift to prevent IO spikes.

Future outlook includes automated operations (automatic anomaly detection and recovery), providing best practices for code management, and tighter integration with the information‑security team for code scanning, vulnerability remediation and risk alerts.