Design and Evolution of APPKIT: A Scalable Mobile Operation Configuration Platform

Background

Meituan and Dazhong Dianping apps are heavily operated applications. Their operation resources (e.g., banners, promotional activities) need to be managed across multiple dimensions such as city, version, platform, and channel. The team needed a stable, flexible, and efficient configuration platform to support rapid version iteration.

Operation Resources

Operation resources are frequently changing assets like ads or activity banners. They are characterized by:

Time‑sensitivity – displayed only within a specific time window.

Strong city relevance – often tied to LBS services and limited to certain cities or regions.

Basic Configuration

Basic configuration includes entry resources, network settings, etc. Compared with operation resources, they change less frequently and are not tightly bound to time or city.

Problems Encountered

Low Operational Efficiency

New configuration requests required developers to build a configuration page, hand it over to operations, and then go through a lengthy release process. Each request could take 1‑2 days of development effort, leading to high cost and long cycles.

Rough Release Process

Initially, configuration changes were hard‑coded in the code base. This caused heavy reliance on code releases, lack of audit mechanisms, and no preview capability before going live.

Our Thinking

We proposed a three‑fold solution, named APPKIT (App Configuration Kit), to address flexibility, efficiency, and stability:

Data JSON‑ization

All configuration data is stored as JSON, allowing dynamic field expansion (title, subtitle, image, link, etc.). A field‑management tool handles the JSON schema.

Process Flow

A three‑stage workflow (draft → process → online) provides pre‑release preview, audit, and rollback capabilities.

SDK‑ization

An SDK runs on business machines, caching configuration locally, reducing dependence on centralized services, and providing asynchronous updates.

APPKIT Architecture

The system is divided into four layers:

4.1 Data Layer

Persistent data is stored in MySQL; hot data is cached in Redis. Three logical domains exist: draft data (editable, no impact on users), process data (under review), and online data (served to C‑end).

4.2 Service Layer

Provides four capabilities: operation backend, open platform, data service, and APPKIT‑SDK.

4.3 Access Layer

Supports the full lifecycle of an operation resource: creation, preview, audit, release, and post‑release rollback. Sensitive resources also pass security checks.

4.4 Monitoring Layer

Monitors SDK instance count, cache size, and data freshness. SDKs report access timestamps; data older than 24 hours is evicted. Periodic sync ensures data is refreshed within one minute.

Stability Evolution

Classic Scheme

Direct service call → Redis cache → MySQL fallback. Issues: network latency, cache jitter, single‑key capacity limits.

Cache Scheme

Added local memory cache to reduce latency, but still suffered from central service bottleneck and cache size limits.

SDK Scheme

Moved caching and data fetching into the SDK, eliminating central‑service pressure and network latency. Introduced challenges of data consistency, cache expiration, and SDK version upgrades, solved by ZooKeeper change notifications and periodic sync.

Effect Comparison

Performance tests show the SDK scheme dramatically reduces latency and stabilizes the system compared with the cache scheme.

Conclusion and Outlook

APPKIT demonstrates how JSON‑based data, process‑driven workflow, and SDK integration can build a high‑performance, flexible, and stable operation configuration platform for mobile apps. It now supports downstream systems such as Picasso (JS management, ABTest, entry management) and is being extended to multi‑platform (Android, iOS, H5, Mini‑Program) operation capabilities.