Architecture Evolution and Microservice Refactoring of a Brand Advertising Platform

As the business and team size grew, the original monolithic architecture of the brand advertising platform became a bottleneck in both development efficiency and system performance, prompting a microservice‑based technical transformation.

The platform underwent three major architectural iterations: 1.0 was a single monolithic application (originally called JinNang) that handled all product‑line advertising; 2.0 split the system into independent platforms per product line while extracting common capabilities into a department‑level base library; 3.0 further reorganised the system into a business front‑end plus seven business middle‑platforms (User Center, Resource Center, Quotation Center, Auction Center, Order Center, Delivery Center, Data Center), achieving service‑level reuse.

Version 1.0 suffered from tight coupling of all product lines, where a minor change in one line could break others, leading to high risk, low development efficiency, and increasing project‑management difficulty.

Version 2.0 introduced product‑line isolation, allowing independent development, testing, and deployment, while still relying on a shared code base. However, many similar business processes (e.g., pre‑sale inquiry, pricing, keyword‑package management) remained duplicated across lines, limiting true reuse.

Version 3.0 defined the seven business centers and a front‑end, each encapsulating a distinct business domain. The centers provide unified capabilities such as user authentication, resource management, pricing, auction, order handling, delivery, and data querying, supporting the full advertising lifecycle from pre‑sale to post‑sale.

The article also distinguishes four levels of reuse: code reuse, module (component) reuse, service reuse, and product reuse, illustrating how deeper reuse yields greater business value.

The drivers behind the evolution are twofold: the diversification of advertising products (driving 1.0→2.0) and the adoption of a middle‑platform governance model to maximise service reuse and accelerate product innovation (driving 2.0→3.0).

During the microservice refactoring, several challenges were encountered: unclear ownership of each microservice, determining appropriate service granularity, the need for automated build/deployment and test environments, comprehensive service governance, and the introduction of distributed transactions.

Solutions include: adopting event‑driven architecture to replace tightly‑coupled RPC calls, using TCC/BTCC patterns for synchronous distributed transactions, employing asynchronous processing with local message tables for time‑insensitive flows, and leveraging department‑level infrastructure for service registration, discovery, monitoring, and fault handling.

In summary, the article presents the historical evolution of the brand advertising platform, analyses the technical and organisational difficulties of microservice migration, and offers practical guidance on middle‑platform practice, component reuse, and governance to balance independent product‑line development with shared capability reuse.