Evolution of Baidu Contract Advertising Platform: From Monolith to Microservices

Background

Contract advertising differs from bidding ads by pre‑negotiating prices, following a four‑step flow: inquiry → order → delivery → settlement. The rapid growth of brand advertising highlighted the need for a unified, scalable platform.

Business Development Stages

Stage 1: Rapid brand‑zone growth (2011‑2018) created many isolated product lines and fragmented platforms.

Stage 2: Integration efforts (2019) unified sales, ordering, and deployment into the Tianqi platform, reducing siloed processes.

Stage 3: Complex marketing scenarios required a consolidated platform (2021‑Q3) supporting multi‑product contracts and unified workflows.

Architecture Evolution

Monolithic Architecture (pre‑2019): Three‑layer design with a unified entry point, independent ad‑placement services, and shared utility libraries.

Microservices Architecture (post‑2019): Four‑layer stack—business front‑end, business middle‑end, technical components (PAAS), and infrastructure (IAAS)—built using domain‑driven design, message‑driven decoupling, and service isolation.

Service Architecture Details

Business Front‑End: Tianqi platform, operation platform, and unified front‑end handling common logic.

Business Middle‑End: Nine domain‑centered services plus two technical centers, enforcing strict upstream/downstream dependencies via domain events.

Technical Components: SpringBoot starters (brand‑starters) provide cross‑service capabilities such as messaging, distributed locks, and caching.

Infrastructure: Cloud‑native solutions (gravity + starlight) replace Zookeeper, offering improved RPC performance, stability, and multi‑language support.

Service Governance

Key practices include timeout settings, retries, circuit breaking, and rate limiting, alongside goals of availability, observability, and anti‑corruption.

Performance Optimizations: Framework upgrades, network improvements, I/O batching, multi‑level caching, async processing, SQL tuning, and API splitting.

Self‑Healing & Self‑Check: Idempotency via DB constraints, optimistic locking, token mechanisms, and event‑log components for automatic recovery and health checks.

Observability

Business‑entity lifecycle tracking via event sourcing, MySQL binlog subscription, and custom SDKs enables real‑time monitoring and proactive issue detection.

Anti‑Corruption Measures

Regular analysis of service change frequency, call patterns, code duplication, and domain boundaries helps prevent architectural decay and cyclic dependencies.

Service Iteration

Adopts forward‑compatible design, automated testing, mock services, and modular releases to reduce risk and improve delivery efficiency.

Conclusion

The evolution demonstrates that effective B‑end system design hinges on managing business complexity through appropriate architectural choices, domain‑driven service decomposition, robust governance, and continuous observability.