Boosting Search Performance with a Golang Concurrent Proxy

Background

Search is a critical entry point for Mafengwo traffic, providing users with destination, POI, attractions, food, hotels, Q&A, guides, and tickets. The original architecture relied on serial function calls to downstream modules, causing high latency (400‑500 ms), strong coupling, linear response growth, and single‑point failures.

Search Technical Stack

Storage – MySQL, Memcache

Module Interaction – Function Call

Retrieval – Elasticsearch

Search Architecture Issues

The three functional modules—Decision System, Agent, and Format—were invoked sequentially, leading to high coupling, long response times, poor scalability, and service outages when downstream modules failed.

Golang Concurrent Proxy Solution

To decouple the search service from downstream modules, a concurrent proxy built with Golang goroutines was developed. The proxy replaces function‑level calls with TCP/IP HTTP interfaces and executes downstream requests in parallel, adding timeout control and fault tolerance.

Key Technology – Goroutine

Goroutine is Golang’s lightweight thread managed by the Go runtime. It uses cooperative scheduling and Linux I/O multiplexing (epoll, select) to achieve high concurrency with low memory overhead (≈2 KB per goroutine), outperforming PHP Swoole or Java threads in CPU and memory consumption.

Proxy Architecture

The request flow is: HTTP Server → Parameter Processing → Parallel Requests (Goroutine Scheduling) → HTTP Module → API Layer. The proxy currently supports HTTP/HTTPS and encapsulates downstream function calls as TCP/IP HTTP interfaces.

Results and Future Plans

After deployment, average search latency dropped to about 240 ms, and the system’s availability, scalability, and resource utilization improved significantly. Future work includes adding RPC support to further enhance service‑oriented architecture.