Design and High‑Performance Practices of Meituan's Settlement and Reconciliation Platform

This article, based on the 23rd Meituan‑Dianping tech salon, describes the architecture, challenges, and optimization techniques of the settlement and reconciliation platform serving Meituan's hotel, ticket, and train‑ticket businesses.

Importance of Reconciliation Reconciliation is the first step of the settlement pipeline; it must accurately calculate merchant and Meituan‑Dianping revenue before payment and invoicing. It must integrate with dozens of order centers, each with different order models and timing, processing millions of transaction records daily.

Early System Practices and Problems The initial system was a single‑threaded, pull‑based design that processed a whole month’s data on the 1st of the next month. This caused severe latency, resource waste, and single‑point failures. New business lines (tickets, train tickets) required faster onboarding (5‑10 days) and higher throughput.

Optimization Strategies 1. Align business change processes with settlement upgrades. 2. Increase data‑processing capacity by moving from single‑thread to multi‑thread, from serial to parallel, and from single‑machine to distributed computing. Sharding by merchant ID and assigning shards to separate servers with dedicated thread pools enabled parallel data fetching and bill generation.

However, this introduced new issues such as server‑level single points of failure and inflexible resource scaling.

Platform‑Level Design The new platform abstracts four core models: order model, calculation‑rule model, merchant‑info model, and a unified "fund language" describing income/expense states. This decouples business logic from settlement logic, allowing each of the 17 business lines to plug in with a small adapter.

Real‑Time Design Transactions are converted to the fund language and pushed via the Mafka message queue to the settlement service, which validates and stores them in MySQL with millisecond‑level latency. A bill engine then aggregates daily bills and triggers calculation rules, using delayed queues for late‑arriving data.

High‑Performance Design To handle millions of bills per day, concurrency is increased at both the bill level (multiple partitions & consumer threads) and the detail level (parallel writes). The traditional transactional lock approach is replaced by a lock‑free design:

//事务保证原子性
try {
    Lock lock = distributedLockManager.getReentrantLock(statementId); //账单维度锁
    lock.lock(); //获取锁，存在阻塞
    insert(detail); //写入明细
    compute(statementId); //计算账单
} finally {
    lock.unlock(); // 释放锁
}

Instead, detail writes and bill calculations are decoupled, eliminating the lock and transaction overhead. A time‑windowed aggregation further reduces DB pressure.

Read‑Performance Optimizations Bill detail tables are sharded by bill ID, and hot data is replicated to HBase for fast SUM queries. Cold data is moved to backup stores, and periodic cleanup frees MySQL space.

Isolation, Customization, and Scalability Different business lines receive dedicated Kafka topics/partitions and consumer groups, allowing independent scaling and fault isolation. The platform supports plug‑in adapters for custom logic, and scaling is achieved across three layers: message middleware, application servers, and the database (sharding, multi‑instance, hot‑cold separation).

Outcome The platform now processes data with millisecond latency, provides real‑time bills to merchants, and supports 17 business lines without cross‑impact.

Author Bio Zi‑Xin, technical lead of the settlement platform at Meituan‑Dianping since 2015.

Recruitment The team is hiring Java backend engineers (contact: zhangzixin03#meituan.com).