Meituan Waimai Advertising Engine Platform Engineering Practice – Part 1
Meituan Waimai’s advertising engine team built a platformized solution that standardizes business capabilities, data handling, and development workflow through reusable Action/Stage units, a unified context container, and a robust scheduling engine, achieving 28% faster development, over 65% Action reuse, and improved quality and stability.
Meituan Waimai’s advertising business has grown rapidly, prompting the advertising engine team to explore engineering solutions and share their findings in a series of articles. This first article introduces the motivation, current challenges, and the overall design of the platformization project.
Problem analysis : The system became increasingly complex as new business scenarios were added, leading to low reuse of business logic, high learning cost for new developers, difficulty for product managers (PM) to obtain information, and challenges for QA to evaluate test scope.
Goals : Since early 2020, the team launched a platformization project aiming to improve production‑research efficiency, delivery quality, and PM visibility through standardization, a technical framework, and a new R‑D process.
Overall design : The platform follows three pillars – business capability standardization, technical capability framework, and a platformized R‑D workflow. It draws inspiration from Alibaba’s TMF and AIOS platforms.
Business standardization : Functions are classified into business‑logic‑related and unrelated. Unrelated functions are abstracted into a two‑layer model (tool layer and component layer) delivered as JAR packages. Related logic is encapsulated as Action units, which are further categorized into base Actions, module Actions, and business‑specific Actions (extensions). Multiple Actions can be combined into a Stage to hide implementation details.
Data standardization : Input, output, and context data are unified via a hierarchical Context container, enabling consistent data passing between Actions. Third‑party data and dictionary (vocabulary) data are also standardized, with a lifecycle management framework for dictionaries.
Process standardization : The execution flow is standardized by defining input and output sets for each Action. Dependency analysis (based on intersecting input/output sets) drives automatic full‑graph DAG compilation, which is then visualized and manually tuned.
Technical framework : The platform consists of a front‑end (Camp platform) for visualization and a backend framework package integrated into engine services. The framework provides scheduling, capability registration, and tool libraries (e.g., dictionary utilities). It supports two scheduling models – layered (BFS‑style) and queue‑pipeline – chosen based on DAG characteristics.
Scheduling engine : Implements static graph construction at service startup and dynamic scheduling at request time. It uses a two‑level thread‑pool model to isolate GraphTask and NodeTask execution, reducing contention and improving stability. Features include condition‑based node execution, timeout handling, and comprehensive monitoring (exceptions, timeouts, statistics).
High‑availability practices : Multi‑tenant isolation, separate thread pools for graph and node tasks, and centralized task dispatch ensure robustness under high QPS.
New R‑D process : Introduces Stage/Action as a unified communication language for PMs, R‑Ds, and QAs. It defines pre‑development design (technical design, project scheduling) and post‑development activities (Action consolidation, feedback collection).
Results : Platformization has led to over 500 shared capabilities, a 28% increase in development efficiency, 65%+ Action reuse for new business, and a 10% reduction in production issues. QA testing coverage improved by 15% and overall delivery quality rose.
Conclusion and outlook : After two years of iteration, the advertising platform now supports multiple business lines with stable performance. Future work will deepen standardization, enhance framework stability and usability, and further refine the R‑D process.
Code example (Action definition and extension):
@LppAbility(name = "POI、Plan、Unit数据聚合平铺能力", desc = "做预算过滤之前,需要把对象打平", param = "AdFlatAction.Param", response = "List<KvPoiInfoWrapper>", prd = "无产品需求", func = "POI、Plan、Unit数据聚合平铺能力", cost = 1)
public abstract class AdFlatAction extends AbstractNotForceExecuteBaseAction {
// ...
}
@LppExtension(name = "数据聚合平铺扩展点", func = "POI、Plan、Unit数据聚合平铺", diff = "默认的扩展点,各业务线直接无差异", prd = "无", cost = 3)
public class FlatAction extends AdFlatAction {
@Override
protected Object process(AdFlatAction.Param param) {
// do something
return new Object();
}
}Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Meituan Technology Team
Over 10,000 engineers powering China’s leading lifestyle services e‑commerce platform. Supporting hundreds of millions of consumers, millions of merchants across 2,000+ industries. This is the public channel for the tech teams behind Meituan, Dianping, Meituan Waimai, Meituan Select, and related services.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
