Brand Synonym Search
Luxury Eyewear Store
Introduction
In this case, user behavior revealed a critical gap: people searched for “Гуччи” (Gucci)”, “Диор (Dior)”, or “Версаче (Versace),” but the system, expecting exact Latin-script brand names, provided no results. This directly affected conversions and user experience— and many users never even reached the product page.
The business needed one clear adjustment; to recognize brand names typed in Russian and return relevant product results.
Nevertheless, our team saw a broader challenge. Adding synonym support wasn’t enough—it had to be scalable, fast, and reliable under any traffic conditions. That’s why, from the outset, we addressed not only business expectations, but also website architecture, performance, and resilience.
System Overview
The platform is a modern e-commerce solution built with Laravel, housing 194 brands and 34,000 products. Initially, it followed a standard relational design: products linked to brands through pivot tables. It scaled well for product growth, but wasn’t prepared for linguistic flexibility or mass text filtering.
When we tried integrating Russian synonyms into the existing structure, performance issues became clear. Each query triggered expensive JOINs—up to 1,500 SQL queries for just 100 searches. Under load, system responsiveness dropped significantly.
Adding to the challenge, there was no centralized method for managing synonyms. Manual input via the admin panel was inefficient and lacked quality control.
Problem #1: Users Search the Way They Want
When someone types “Гуччи (Gucci)”, they expect to see Gucci products. That’s a given for any serious e-commerce site.
We implemented full synonym support. First, we used an AI language model to generate transliterations, colloquial forms, and popular variations. Then, our content team reviewed and refined the lists manually for precision.
Synonyms were imported via CSV files, allowing admins to update the database quickly and centrally—without developer involvement.
Problem #2: Search Architecture Was Hammering the Database
We realized that as data grew, keeping the current structure would cripple performance.
So we made a strategic decision to denormalize. Brand synonyms were embedded directly into the product model. Searches were now executed on the main product table—no more JOINs. This reduced database load dramatically.
We also made synonym syncing between brands and products asynchronous via Laravel’s events and queues, ensuring stability even during traffic spikes.
Problem #3: Bulk Updates Must Be Production-Safe
Updating synonyms shouldn’t slow down or crash the site. Users shouldn’t feel a thing.
All updates now run in the background. When a brand’s synonyms change, an event triggers a queue to update all related products. The load is distributed and has zero impact on frontend performance.
| Metric | Before Optimization | After Optimization |
|---|---|---|
| SQL queries per 100 searches | ~1,500 | ~100 |
| Average search response time | ~800 ms | <120 ms |
| Conversion from search | ~2.5% | >4.1% |
| Scalability | Limited | High |
SQL queries per 100 searches
~1,500
~100
Average search response time
~800 ms
<120 ms
Conversion from search
~2.5%
>4.1%
Scalability
Limited
High
We didn’t just add synonym search—we made it robust, lightning-fast, and ready to scale. The client now has a future-proof foundation, not just a patch for one pain point.
Conclusion
This project proves that when a business challenge meets proactive engineering, the result can exceed all expectations.
The next step? Predictive search and advanced query interpretation.
The outcome: smarter search, a more stable platform, and a client team empowered to manage data independently.