How Baidu Revamped Visual Search: From PHP to Golang and Graph Engine

Background

Visual search uses image recognition and deep learning to retrieve results based on user‑uploaded pictures, serving scenarios such as education, e‑commerce, and wildlife identification. Rapid product iteration and scaling pressures demanded continuous technical innovation and architectural upgrades to keep the service competitive and adaptable.

Key Challenges

Legacy stack (PHP + HHVM) lacked support for async/multithreading and was no longer maintained.

Monolithic modules caused complex inter‑module interactions, higher latency, and difficult troubleshooting.

Stability needed reinforcement as the system grew in size and complexity.

Solution Overview

The redesign tackled three pillars: technology‑stack upgrade, architectural capability enhancement, and stability construction.

2.1 Overall Design

The project reconstructed the full‑link architecture, integrating a shared internal tech stack while preserving Baidu’s proprietary infrastructure. A new system diagram (see below) illustrates the end‑to‑end layout.

2.2 Detailed Design

2.2.1 Access Module (Visual BFF)

A Backend‑For‑Frontend layer provides unified multi‑device adaptation and dynamic routing. The processing flow includes service initialization, multi‑device request parsing, routing decisions, and result output.

2.2.2 Presentation Module Refactor

The presentation layer was rewritten in Golang using Baidu’s internal GDP framework and the ExGraph graph engine. Key steps:

Framework selection: GDP offers RPC server/client capabilities for API, web, and backend services.

Module decomposition: Separate BFF from UI logic to isolate business concerns.

Logical layering: Define clear UI layers to simplify long‑term maintenance.

Graph‑based transformation: Encapsulate common and business‑specific operators as graph nodes, enabling flexible orchestration.

2.2.3 System Layer Refactor

Addressing module interaction complexity, massive monoliths, and data‑protocol inconsistencies, the team:

Introduced layered design within the presentation service to improve reuse and enable asynchronous execution.

Consolidated retrieval interfaces into a unified graph‑driven pipeline, delivering all recall results and strategy signals in a single request.

Decoupled large monolithic components by reassigning responsibilities across layers.

Standardized data protocols and templates, adding feature and logging channels to eliminate opaque data passing.

2.2.4 Stability Infrastructure

Stability was reinforced through a five‑stage pipeline: perception → handling → prevention → root‑cause analysis → inspection. Monitoring leveraged the GDP framework’s Prometheus‑based metrics, covering environment health, framework internals, business KPIs, downstream effects, and end‑to‑end outcomes.

Key fault‑handling mechanisms include:

Automated instance migration and elastic scaling via an ALM (Application Lifecycle Management) system.

Custom pprof collection (Keeper) triggered on alerts to preserve diagnostic snapshots.

Support platforms such as a research sandbox, debug visualizer, and trace collector to accelerate issue reproduction and log analysis.

Conclusion

The visual search platform’s evolution demonstrates how a systematic upgrade of the tech stack, graph‑based architectural redesign, and robust stability tooling can sustain rapid product cycles and AI‑driven feature growth. The shared lessons are applicable to any large‑scale, image‑centric service facing similar scalability and maintainability pressures.