How WizardLabz migrated a production eCommerce platform from database search to Elasticsearch — without breaking the frontend or risking downtime.
Migrated product search from traditional database queries to a dedicated search engine
Indexed over 50,000 products with full variant and attribute support
Implemented queue-driven indexing to keep search results synchronized in real-time
Built variant-aware search so customers find the right size, color, and configuration
Validated system stability during Black Friday traffic peaks
Preserved database fallback to ensure zero-downtime safety
When customers search for products on an eCommerce site, they expect instant results. Every second of delay costs conversions. Studies show that a one-second delay in page response can result in a 7% reduction in conversions.
This client's platform had grown to over 50,000 products. Their search was powered by traditional database queries — the same database handling orders, inventory, and customer data. As traffic grew, so did the strain.
The business needed search to be fast, independent, and ready to scale — without rebuilding their entire platform.
WizardLabz designed and implemented a dedicated search system that runs alongside the existing platform. The approach was deliberate: minimize risk, preserve what works, and add capability without disruption.
We introduced Elasticsearch as a dedicated search layer. The existing database remained the source of truth for products. Search simply got its own optimized infrastructure.
The existing storefront, product pages, and checkout remained untouched. The new search engine plugged into the existing API layer, so the frontend didn't need to know the difference.
We didn't flip a switch. Search was rolled out in phases — first for internal testing, then for a percentage of traffic, then fully. This allowed validation at each step.
If the search engine ever became unavailable, the system automatically fell back to database search. Customers would experience slower search, but never broken search.
| Metric | Before | After |
|---|---|---|
| Average search latency | 2,400 ms | 65 ms |
| Peak traffic search response | 4,000+ ms | 120 ms |
| Database CPU during search | 75-90% | 25-35% |
| Index update delay | N/A (real-time DB) | < 5 seconds |
| Search availability | Tied to DB health | Independent + fallback |
The system was designed for reliability and independence. When a product changes, the update flows through a queue to the search engine. Search results come from the optimized index, with the database ready as a fallback.
By separating search from the core database, we eliminated resource competition. The database could focus on transactions while search scaled independently.
The fallback mechanism meant there was never a scenario where search would be completely unavailable. Risk was managed at every layer.
We didn't bet everything on a big-bang launch. Gradual rollout allowed us to catch issues early and build confidence with real traffic.
The architecture was designed to grow. Future enhancements — faceted filters, personalization, even AI-powered search — can plug in without rewriting the foundation.
The white paper includes complete architecture details, queue design patterns, index modeling, variant handling logic, fallback implementation, admin tooling, Black Friday stress test results, and future roadmap including vector search.
Download the Full White Paper (PDF)No email required. Direct download.
Wizard LabZ LLC
WizardLabz specializes in building and scaling production systems for businesses that can't afford downtime. With over 20 years of combined experience across eCommerce, fintech, and enterprise software, we focus on solutions that work — not experiments.
Explore how we've helped other businesses build systems that scale.