Design and Implementation of a Testing Quality System for the 58.com SSP Advertising Platform

The SSP platform, developed by 58.com’s middle‑office commercial department, serves as a unified, robust, and flexible system for online advertising, storing around 13 GB of configuration data such as selling channels, prices, and discounts, making its stability critical for ad delivery.

Its architecture consists of three layers: a web layer (SSPManager) for product and operation teams to configure data, a service layer (SSPMain) that processes and writes the data to storage, and a data layer comprising MySQL, local cache, and Redis, each holding different parts of the advertising data.

Three major problems were identified: (1) ensuring that data entered via the web UI remains consistent and correct when persisted to the database; (2) reducing the regression workload and guaranteeing stability of the 25 external query interfaces when service changes occur; and (3) maintaining consistency among MySQL, Redis, and cache as the data changes in real time.

The proposed testing quality system addresses these issues in three corresponding layers: web‑layer input consistency checks, service‑layer automated interface testing (running every 30 minutes with email alerts on failures), and data‑layer quality monitoring for Redis‑stored channel and price data.

For the data‑layer, a custom automation tool was built to generate test data from Excel files, automatically populate MySQL and Redis via APIs, and compare expected results stored in Excel with actual Redis query results, thereby eliminating manual data construction and verification errors.

Monitoring tools were implemented to detect abnormal price adjustments and channel deletions: price anomalies trigger email and WeChat alerts after comparing real‑time prices with daily backups, while channel deletions are identified by daily Hive backups of Redis data and alerting when a significant drop is detected.

Three approaches for large‑file comparison were evaluated—hash/MD5, database loading, and chunked reading—with the chunked reading method chosen for its simplicity and efficiency.

The current system runs stably online, performing monitoring once a day with ~3 minutes execution time, and uses ZooKeeper notifications to keep cache and MySQL synchronized.

Future work includes automating the repair of abnormal price data, increasing the real‑time capability of channel‑deletion monitoring, and isolating price‑data retrieval from live production systems.