How a Scalable Business Search Platform Powers Billions of Queries in WOS

Background

The Weimob Business Search Platform plays a crucial role in the Weimob New Business Operating System (WOS), providing search services for billions of records across core domains such as promotions, products, transactions, and members. By standardizing event ingestion, workflow construction, and search, it offers low‑cost, high‑efficiency search capabilities while reducing dependence on search‑specific technical details and resource maintenance.

Why a Business Search Platform?

Traditional chimney‑style architecture suffers from several drawbacks. Its advantages include resource isolation, rapid iteration, business independence, and simple logic where read/write can occur within a single application. However, it also brings technical dependency, high management cost, data silos, difficulty ensuring data consistency, poor reusability, limited scalability, and poor manageability.

Business Scenarios and Search Requirements

Current integrated businesses fall into two categories: management‑side (low‑frequency, high‑real‑time requests) and user‑side (high‑frequency, bursty traffic during promotions). Search needs are categorized as single‑domain (e.g., member list with multi‑condition queries) and multi‑domain (e.g., combined activity and product search).

Challenges of the Business Search Platform

Business isolation: Both data and query isolation are required; each tenant receives a unique identifier, and authorized cross‑business queries are supported.

Model management: Business models are decoupled from Elasticsearch models via mapping tables, allowing conversion during write and reverse parsing during read, preventing index field bloat while preserving business independence.

Index construction: A node‑based execution framework builds indexes by recognizing node relationships and processing them accordingly.

Design Solution

The platform is divided into three responsibilities: event ingestion service, index construction service, and search service. All actions are abstracted as events, index‑building steps as workflow nodes, and search scenarios as generic queries detached from business logic.

1. System Architecture

2. Event Ingestion Service

Handles event intake, transformation, and distribution. Supports multiple protocols (Canal, Artemis, Dubbo) and defines event sources, scenarios, model objects, state persistence, and routing to appropriate processing queues.

3. Index Construction Service

Executes event lifecycles, converts business models to index models, orchestrates node execution, and performs deduplication, aggregation, idempotency, and rate‑limiting. Specialized lock‑free handling improves performance.

4. Search Service

Provides business‑side management, query scenario configuration, generic search protocol, and controls routing, caching, and degradation strategies.

Value

Cost reduction: Unified model abstraction cuts hardware usage by ~50%.

Efficiency: Standardized, configurable pipelines enable new business integration within a day and rapid iteration for existing services.

Performance: Handles daily billions of calls, peak 100k QPS, with average latency of 2‑3 ms.

Focus separation: Business teams concentrate on product features while the platform handles search technicalities and stability.

Future Plans

Configuration: Centralize tenant registration, index, and cluster management.

Visualization: Dashboard for service metrics.

Simplicity & usability: Lower entry barriers, provide performance diagnostics, and automate governance and operations.

Conclusion

The article presents the design exploration of the Business Search Platform, covering its background, architecture, detailed design, and optimization measures. It currently serves multiple product lines within the Weimob group and will continue to evolve, enriching features and supporting more businesses while inviting interested peers to collaborate.