Search Platform Architecture Evolution at a Large E-Commerce Platform

Search in a large e-commerce platform is more than a query box. Product, store, price, and promotion data must first move from several business systems into an index. Each customer query then passes through retrieval, filtering, ranking, and caching before the page can display a result. A failure anywhere in that path may appear as a missing product, stale information, or slow responses during a major promotion.

This project established shared product-search and content-distribution capabilities for multiple business lines. It covered index construction, query processing, caching, ranking, controlled experiments, release, and monitoring. The platform served more than 30 million users and exceeded 5,000 QPS at peak.

Role and key responsibilities

I served as software architect and search-platform lead. I led the architecture, service boundaries, and critical-path design, while also contributing to requirement review, task decomposition, technical review, core development, code review, and cross-department coordination. The search team delivered the platform jointly; I held the leading responsibility for the solution and its core implementation.

The work included:

• separating indexing, querying, caching, ranking, experimentation, and monitoring into well-defined platform capabilities;
• redesigning Elasticsearch indexes and query paths for lower latency under complex queries and peak traffic;
• introducing Redis hot-data warm-up and a local second-level cache;
• establishing rate limiting, circuit breaking, canary release, and tested rollback paths;
• connecting data synchronisation, index state, and query metrics so missing results could be traced across the business path;
• standardising CI/CD to reduce manual deployment steps and environment drift.

Supporting change without destabilising search

The purpose of a shared search platform was not to force every business line into identical behaviour. It standardised common contracts—pagination, filtering, sorting, timeout, and error semantics—while allowing business-specific fields and ranking policies through controlled configuration and extension points.

Full index builds and incremental updates followed consistent version rules. Operators could trace an item from its upstream change through processing and into the final document, then use idempotent replay to restore missing data safely. On the query side, caching, resource isolation, and degradation policies prevented a local dependency problem from immediately overwhelming the main search entry point.

Major index or query changes ran old and new versions in parallel. The team compared coverage and important queries, shifted traffic gradually, and retained a verified fallback. This added short-term operating cost but turned release risk into an observable and controllable process.

Outcomes

• P95 latency on the core path fell by 40% after the Elasticsearch index and query redesign.
• Availability increased from 99.5% to 99.9%.
• Multi-level cache hit rate exceeded 95%, with no failures during peak promotion traffic.
• Standardised delivery and rollback improved deployment efficiency by 60% and reduced manual intervention by 80%.

The result was not a single performance fix. It established an architecture that could continue to evolve across capacity, reliability, delivery speed, and incident recovery.