Backend Architecture Refactoring with Golang: Design, Data Flow, and Performance Optimizations

Author Zhang Hongtao, with over 10 years of software development experience at companies such as Sohu and Sogou, presents a backend architecture refactoring project aimed at improving search relevance, response latency, and conversion rates.

Current Issues

Search is implemented over the full data set, yielding unsatisfactory results.

Long API response times degrade user experience.

Inability to perform secondary data optimizations.

Relatively low conversion rate.

Refactored Version

Process only a subset of optimal data selected asynchronously offline based on data models.

Require real‑time filtering and fast response to ensure good user experience.

Optimize data to increase conversion rate and GMV.

Why Golang

Powerful built‑in concurrency support.

Performance comparable to C, suitable for CPU‑intensive calculations.

Based on these reasons, Golang was chosen as the server‑side computation language.

Refactored Architecture Diagram

Explanation of each module:

Nginx+Lua renders pages and fetches JSON data from the Go computation service for final presentation.

Config Center coordinates workers, Lua services, and Go computation nodes.

Score Worker and Data Worker perform offline asynchronous calculations, pull data from the data platform, apply models, store results in the DB, and notify Config Center.

The highlighted yellow component is the Go computation service, deployed in two clusters (online and offline). The offline cluster pre‑loads data into sharded Redis and Go nodes, then can be switched to online service on demand.

MQ Worker processes messages such as SKU up/down, inventory changes, and price updates.

Msg Receiver consumes MQ messages and forwards them to the appropriate Go computation nodes.

Multiple data‑center deployments avoid single‑site failures.

Data Processing Flow Diagram

The core of the flow is the Config Center; every step depends on it, making it a critical component of the architecture.

In‑Memory Computation Model Diagram

Computation steps:

Parse request parameters into structured Go structs.

Normalize fields such as brand, price, SKU attributes, inventory, tags, and sort type.

Perform in‑memory filtering, sorting, and other calculations.

Obtain the list of product IDs required for the current page.

Fetch detailed product information by ID and apply additional attribute filtering.

Return the structured JSON to Lua for page rendering.

In‑Memory Data Structure

The diagram shows a Go struct that contains all attributes needed for computation; each product is represented by such a struct, and tens of thousands of structs are pre‑loaded into memory after data heterogenization to avoid runtime initialization overhead.

Challenges Encountered

Low serialization performance of Go's built‑in encoding/json and encoding/gob.

Garbage‑collection overhead, especially during the Mark phase.

Solutions:

Adopt ffjson (via the author of Beego) which is about three times faster than the standard JSON library.

Reduce the number of objects in memory, reuse objects via object pools, enable GODEBUG=gctrace=1 for GC tracing, and use the built‑in pprof package for CPU and memory profiling.

Go Technology Stack

Web framework: Beego (Asta) with its ORM; MVC design simplifies API definition and routing.

JSON serialization: ffjson (https://github.com/pquerna/ffjson).

Redis client: go‑redis (https://github.com/go-redis/redis) with an internal wrapper for master‑slave handling.

— End of article —