Design and Architecture of Specialized Search Services

What is Specialized Search

Search results consist of natural results, which are retrieved from the Internet based on relevance algorithms, and specialized results, which are pre‑processed offline (e.g., via knowledge graphs) and returned directly for specific queries such as "Game of Thrones" where encyclopedia, novel, and video entries appear first.

Specialized Search Service Model

The model must meet strict performance requirements and has two key characteristics: openness (multiple independent services contribute to a single request) and convergence (aggregating multiple specialized results). This results in a tree‑like structure where leaf nodes are open services and non‑leaf nodes aggregate results.

Architecture Design

An extreme approach would let each service operate independently and be accessed via RPC, but this leads to waste and chaos. Important concerns include defining a common interface, unified traffic distribution, efficient service calls, and shared components such as logging, caching, and in‑memory dictionaries.

Interface Standard

To reduce aggregation cost, a simple protobuf service definition is used:

service ServiceAPI {    rpc query(message.Request) returns (message.Response); };

The Request message is uniform across services, while Response is extensible to accommodate varied service results:

message Response {    // common fields ...    repeated Result = 10; };

message Result {    // common fields ...    extensions 128 to 512; };

Alternatively, custom messages can be embedded directly in Result when required.

Traffic Distribution

Traffic distribution determines how a user request is routed to services. Two base classes are provided: AtomicService for services that handle the request entirely, and AggregatedService for services that forward and aggregate results. Registration follows an inversion‑of‑control pattern, allowing new services to register themselves without modifying upstream code.

Two routing strategies are discussed: full‑traffic forwarding (downstream decides processing) and query‑analysis‑based routing (upstream parses the query and selects target services). The implementation adopts the latter, with registration syntax such as:

[@service]
name : any-service
address : 100.100.100.100:1234
accept_ids : [1, 2, 10-20]

Service Invocation

Service invocation must handle loading and discovery. Independent processes can register with an RPC framework like gRPC. For performance‑critical scenarios, multiple services may run in a single process and be invoked via function calls inside a container. The container tracks whether a target service resides internally (function call) or externally (RPC). Isolation constraints limit which services can share a container.

Other Considerations

Online services often perform traffic sampling for experiments, treating each experiment as a separate service and including experiment IDs in routing decisions. Common component development (e.g., logging, caching) is omitted for brevity.