Inside Xiaomi’s Ad Platform: Architecture, Evolution, and Lessons for Backend Engineers

Ouyang Chen, a senior architect at Xiaomi, leads the architecture and development of the Xiaomi advertising platform. He holds a bachelor's and master's degree in Computer Science from Peking University, previously worked 10 years at Microsoft on search and ad systems, and 3 years at Oracle on database and application server development.

Can you briefly introduce yourself, your current role, and summarize your career?

I am Ouyang Chen, currently an architect and R&D manager at Xiaomi, responsible for the ad platform architecture, ad transaction system development, and marketing data platform. Previously I spent 10 years at Microsoft leading teams on internet advertising and search engine technologies, and earlier I worked on database development at Oracle.

How did you get into technology, and how do you keep your passion alive after 15 years of experience?

From a young age I was fascinated by engineering. Studying computer software at Peking University deepened that interest. I continuously learn new technologies, solve problems, and refine products to meet business goals, which fuels my enthusiasm. Setting short‑ and long‑term goals, staying curious, and embracing a craftsman spirit help me maintain motivation.

What is the size and structure of the Xiaomi ad platform technical team?

The platform serves Xiaomi’s mobile internet advertising across app store, news, video, browser, TV, and other premium resources, offering formats such as app distribution, feed, e‑commerce, splash, pre‑roll video, and themes.

The R&D team consists of dozens of engineers and is growing. It is organized by business goals into media, system architecture, strategy algorithms, advertiser services, and data platform groups.

Can you describe the data landscape supported by the platform?

With over 150 million Xiaomi devices sold and daily active users in the hundreds of millions, the platform leverages massive user data. The app store sees up to 80 million daily downloads, and the built‑in news feed reaches tens of millions of daily active users, providing rich data for ad targeting and measurement.

What is the overall architectural design philosophy?

The design starts from a deep understanding of current and future business needs, aiming to reduce coupling by isolating rapidly changing modules. It aligns with Conway’s Law, ensuring the architecture matches the organization’s structure and provides flexibility for fast‑moving business units. High reliability, scalability, and support for agile, incremental development are also key considerations.

How did the platform evolve over time?

The evolution follows four stages: "add", "subtract", "multiply", and "divide".

"Add" – rapid addition of new business features increased system complexity and coupling.

"Subtract" – decoupling modules into services reduced unnecessary inter‑dependencies.

"Multiply" – stable business allowed modular services to scale independently, enabling stream processing, faster algorithm deployment, and improved capacity and reliability.

"Divide" – massive growth in services and infrastructure led to abstracting service groups and optimizing large‑scale offline data flows, simplifying the overall system.

The goal is to balance cost, quality, revenue, and speed while supporting rapid business growth.

What are the core modules and how are they implemented?

Ad Index Service – builds searchable indexes for advertisers, using a custom inverted index and Lucene for parts of the system. Real‑time index updates ensure data consistency.

Click‑through Rate Prediction and Ranking – predicts clicks for each ad request, supports rapid algorithm rollout and experimentation, and handles increasing feature data with horizontal scaling and reduced latency from hours to minutes.

Data Platform – provides anti‑fraud monitoring, business intelligence, reporting, and a DMP for precise marketing, helping advertisers optimize budgets and measure performance.

What major pitfalls did you encounter and how were they resolved?

Early on, unclear layer boundaries caused high code duplication. A comprehensive “blueprint” was created, but only stable modules benefited from refactoring; other modules evolved naturally and proved more adaptable to new business needs.

MySQL scaling challenges: read/write splitting, vertical sharding, horizontal sharding, and eventually moving parts of the data to HBase. The effort was costly and short‑lived, leading to the insight that adopting NoSQL earlier would have avoided unnecessary MySQL overhead.

What are the biggest current challenges?

The platform must support diverse and fast‑moving business requirements with a highly flexible architecture, while extracting maximum value from data to improve user experience, advertiser ROI, and media monetization.

Advice for engineers aspiring to become architects?

Be an excellent programmer, embrace learning from failures, understand that architects solve real business problems using data‑driven methods, and balance cost, speed, and quality. Continuously improve technical breadth, communication, and data insight skills to persuade stakeholders and drive projects forward.