Haier E‑Commerce Platform Architecture: SOA, Dubbo, and Product Service Design

Most e‑commerce platforms experience rapid traffic and revenue growth, facing massive system stress during events like Double‑11 and anniversary sales, which can be dozens of times higher than normal, demanding robust architectural planning.

Since 2012, Haier has pursued "three‑transformations"—platformization, user personalization, and employee maker‑culture—providing a strong foundation for its e‑commerce growth and presenting similar challenges.

SOA Architecture on the Shoulders of Giants

As business scales, system complexity increases, requiring domain‑level service decomposition and extensive sub‑site splitting; SOA offers clear structure and logical organization, facilitating business optimization and new service development.

Service encapsulation and strict separation lay a solid foundation for high scalability, making client impact assessments and refactoring straightforward.

Dubbo, an open‑source RPC framework from Alibaba, delivers excellent performance under high concurrency; Haier's SOA fully relies on Dubbo. Each service provider registers with a registry, maintains a long‑living heartbeat, and consumers obtain provider lists from the registry before establishing direct long‑connections, enabling load balancing, fault tolerance, and monitoring.

Figure 1: Dubbo service deployment diagram.

All Haier e‑commerce services are built on Dubbo; the overall SOA architecture is shown in Figure 2.

Figure 2: Haier e‑commerce SOA architecture.

Balancing Performance and Flexibility in Product Service Architecture

Challenges

High load weight: product display and search dominate front‑end traffic, requiring high availability, performance, and scalability.

Great product diversity: varying attributes across categories demand a generic and flexible data model.

Comprehensive search and sorting: users need fast, multi‑dimensional search, including keyword, category, and attribute filters, often requiring complex logic and real‑time analytics.

Static page generation reduces backend load but sacrifices control for advanced automation; therefore, improving backend performance and scalability is preferred.

Performance and scalability are critical; sometimes functionality must be sacrificed to meet these goals.

Solution

At the database layer, a fine‑grained relational model supports complex product structures, freeing the client from storage concerns.

Figure 3: Product service logical architecture.

The product query engine encapsulates the complex storage model into a simple logical model, exposing a DSL for client queries; the DSL resembles SQL WHERE clauses and can even be written in Chinese for business users.

Figure 4: DSL workflow.

The query engine consists of a compiler (built with ANTLR) that transforms DSL expressions into syntax trees with optimizations, an execution engine that matches products, a smart ranking engine based on a competitiveness model, and a result constructor that assembles requested attributes.

Figure 5: Query engine mechanism.

Product data is cached in memory at service startup and refreshed via MQ messages on changes.

Product Service Architecture

Services are deployed in separate clusters; web‑facing clusters rarely hit the database, eliminating database bottlenecks even under peak traffic, with scalability achieved simply by adding web or service nodes.

Results

Performance: peak 260 million requests per day, average 60 ms per request, with further optimization potential.

Scalability: near‑linear scaling; no additional designs needed for high load.

Generality: the model works for internal PDM systems and other online services without restrictions.

Extensibility: logical model shields underlying data model, minimizing impact of schema changes.

The query‑engine‑centric product service demonstrates a design that simultaneously achieves performance, scalability, generality, and extensibility for large‑scale e‑commerce platforms.