From Slow, Distributed Queries to Fast and Scalable Product Discovery
Overview
The client is a leading booking and activity platform that works with local destination partners, tour operators, and other vendors. Its platform enables partners to sell travel products through dedicated websites, with each site containing a searchable product catalogue.
As the platform expanded, product information became distributed across several microservices. Searching this information required the application to communicate with multiple services, retrieve data from different databases, combine the results, and then apply the requested filters.
This architecture supported the wider booking platform effectively, but it was not ideal for complex and interactive product discovery. Search requests became increasingly expensive, particularly when users applied several filters or when multiple partner websites experienced high traffic at the same time.
The client needed a search experience that could return relevant products with minimal delay, support advanced filters without overloading operational services, handle multilingual product information, remain accurate as product data changed, scale across multiple partner websites, and integrate smoothly with the existing Vue.js and Golang application stack.
After evaluating different search technologies, including Elasticsearch and Algolia, we implemented Algolia as a dedicated search layer. The new architecture separated product discovery from transactional microservices while keeping search records synchronised through background processing.
The result was a faster and more responsive catalogue experience, a reduced dependency on cross-service queries, and a scalable foundation for future search improvements.
What Is Algolia?
Algolia is a managed search and product discovery platform that helps applications deliver fast and relevant search results. Instead of running complex search queries directly across multiple databases or microservices, businesses can send searchable data to an Algolia index that is specifically structured for quick retrieval.
Algolia is commonly used in e-commerce websites, booking platforms, marketplaces, documentation portals, and content-heavy applications where users need to find information quickly.
It provides capabilities such as:
- Keyword and typo-tolerant search.
- Advanced filtering and faceted navigation.
- Custom ranking of search results.
- Search suggestions and autocomplete.
- Multilingual search support.
- Search analytics and relevance optimization.
- Software development kits for frontend and backend integration.
In this project, Algolia worked as a dedicated search layer rather than replacing the platform’s operational databases. Product data remained managed by the existing microservices, while selected searchable information was synchronised with Algolia through background jobs.
This allowed Algolia to handle search, filtering, and result ranking efficiently while the core microservices continued managing product updates, availability, suppliers, and booking operations.
Challenges
The primary challenge was not simply adding a search box. The platform already allowed customers to search for products. The real challenge was delivering fast, accurate, and filterable results across a distributed microservices environment.
Search Data Was Distributed Across Multiple Services
Different microservices managed different parts of the product domain. One service handled product details, while others managed categories, destinations, suppliers, pricing, availability, translations, and partner-site configuration. As a result, a single catalogue request often required several internal API calls before the platform could display complete results. These additional network calls increased response time, while one slow or unavailable service could delay the whole request or return incomplete information. Complex filters also required data from multiple sources, and frequent search requests placed extra load on transactional services. Although microservices improve service independence, using operational services directly for search creates unnecessary coordination and performance overhead.
Advanced Filtering Increased Query Complexity
Customers needed more than basic keyword matching. They wanted to narrow products using criteria such as destination, product category, supplier, language, price range, availability, tags, and other catalogue-specific attributes.
Applying these filters across different databases required complicated query construction and data aggregation. As more filter combinations were introduced, the search flow became harder to optimise and maintain.
The client needed filtering that remained responsive even when several conditions were selected together. Algolia supports filtering through numeric, facet, and tag attributes, including Boolean combinations. Its faceting capabilities also allow interfaces to display filter values and matching result counts, which makes it suitable for interactive catalogue navigation.
Search Queries Were Affecting Operational Workloads
The same services responsible for booking operations and product administration were also supporting catalogue discovery. This created competition between transactional workloads, such as updating products and processing bookings, and search workloads, such as text queries, filtering, sorting, and browsing results. Search activity could generate a large number of read operations, especially when users typed continuously or changed filters. Allowing these requests to reach multiple production services increased database load and created a risk that catalogue traffic could affect more important booking workflows.
The Platform Required Multilingual Search
The client operated partner sites for different destinations and audiences, with product names, descriptions, categories, and other searchable information available in multiple languages. This required careful decisions about whether to store all languages in one index or use separate indices, how to structure translated fields, which language-specific search settings to apply, how to control duplication and indexing costs, and how to return the correct language for each partner website. Algolia supports multilingual content through both single-index and multiple-index approaches, but proper language configuration is important because features such as stop-word handling, plural recognition, and typo tolerance depend on the selected language settings.
Why This Mattered
Search is one of the main entry points into a booking journey. When customers cannot find a suitable activity quickly, they are more likely to abandon the catalogue before reaching the booking stage. The client therefore needed to improve search performance without creating a major rewrite of the existing microservices architecture.
Strategy
The team investigated technologies capable of providing fast full-text search, filtering, indexing, and scalable query handling.
Elasticsearch offered extensive control and customisation, but it would also require additional infrastructure management, cluster configuration, scaling decisions, monitoring, tuning, and operational expertise. Algolia offered a managed search platform with client SDKs, configurable ranking, faceting, filtering, multilingual support, and a faster implementation path.
Because the client wanted to improve the search experience quickly, Algolia was selected as the most practical option for the project. The goal was not to replace the existing databases. Instead, Algolia would operate as a read-optimised search index while the existing services remained the systems of record.
Solution Architecture
1. Source Microservices
The existing Golang microservices continued to manage the authoritative product data, including product creation and editing, supplier and partner configuration, categories and tags, pricing and availability, translations, and publication status. Algolia did not replace the primary databases; instead, it worked as a dedicated search layer. This reduced migration risk and allowed transactional workflows to continue operating normally.
2. Background Synchronisation Layer
When relevant product data changed, a background job prepared an updated search record and sent it to Algolia.
The synchronisation workflow followed this general pattern:
- A product or related entity was created, updated, or removed.
- The responsible service recorded the change.
- A background job collected the necessary searchable fields.
- The data was transformed into the agreed index structure.
- The corresponding Algolia record was created, partially updated, or removed.
- Failures were logged and made available for retry.
Using background jobs prevented product-management requests from waiting for an external indexing operation. It also provided a controlled place for retries, monitoring, and error handling.
Algolia supports partial record updates, which make it possible to update selected attributes without replacing every field in a record. This is useful when different services own different parts of the searchable product representation.
Where several services could update related data concurrently, the design also had to consider ordering, version checks, and idempotency so that an older update did not overwrite newer information. Algolia documents version-based concurrency handling as one approach for protecting index consistency in concurrent environments.
3. Search Index and Data Model
The search record was designed specifically for the catalogue experience instead of copying complete database tables into Algolia.
Each indexed product contained only the information needed for search and product discovery. This included the product ID, partner-site identifiers, product title, short description, destination, location, categories, tags, supplier details, product status, translations, pricing information, filterable attributes, display image, product-page URL, and ranking signals where available.
Keeping only the required information made the search records smaller and easier to manage. It also allowed the frontend to display product results immediately without calling several microservices for every product card.
In this way, Algolia stored a search-optimised version of the product catalogue rather than acting as a direct copy of the platform’s databases.
4. Search Experience Layer
The search interface was developed in Vue.js using Algolia’s JavaScript SDK. Instead of sending every catalogue search request to the main application backend, the frontend queried the Algolia index directly using a restricted search key. This reduced unnecessary backend processing while keeping the index protected from unauthorized changes.
The search page supported both keyword-based search and advanced catalogue filtering. Depending on the configuration of each partner website, users could narrow results by destination, product category, product type, price range, supplier, language, tags, features, publication status, and other partner-specific attributes.
Only the fields that genuinely required interactive filtering were configured as facets. Attributes used only for filtering could be set with Algolia’s `filterOnly` option. This avoided calculating unnecessary facet counts, helped keep the index smaller, and supported better search performance.
Multilingual Index Design
The multilingual structure was designed carefully because an unsuitable model could increase indexing operations and complicate relevance configuration.
The team considered two main approaches:
A shared multilingual index
This approach stores translated fields in the same product record. It can reduce duplication and simplify cross-language product management, but the record design and ranking rules become more complex.
A separate index for each language
This approach allows language-specific ranking, searchable attributes, stop words, and typo configuration. However, it can increase record duplication and indexing operations.
The final structure was selected according to the platform’s translation model, partner-site requirements, and cost considerations. The important architectural principle was to treat multilingual search as an index-design decision rather than merely adding translated text fields later.
Search Security
The frontend was not given an Algolia administration key. Instead, the implementation used restricted search credentials that allowed catalogue queries but did not permit users to modify index records or settings.
Index-writing credentials remained within trusted backend services and background workers. Where partner sites required strict catalogue separation, search filters could be enforced through secured or restricted access patterns so that one site could not retrieve products belonging exclusively to another site.
Reliability and Recovery
Because the Algolia search index contained a search-optimised copy of the operational product data, the system needed a reliable way to recover or rebuild it when required.
For normal product changes, the platform used incremental synchronisation. This meant that only the affected product records were created, updated, or removed from Algolia. For the initial setup, major index-structure changes, or recovery from a serious synchronisation issue, the platform could perform a controlled full reindexing of the product catalogue.
Separate indices were maintained for development, staging, and production environments. This allowed the team to test changes to searchable fields, filters, ranking rules, and index settings before applying them to the live search experience.
Monitoring was also added to track failed indexing jobs, retry attempts, data-transformation errors, differences between source products and indexed records, search failures, unusual increases in indexing operations, and overall search behaviour. This visibility helped the team identify synchronisation issues early and maintain accurate search results.
Technologies Used
The search optimization solution was developed using Vue.js, HTML, CSS, JavaScript, and TypeScript for the frontend. Golang was used for backend services and background data synchronisation. The implementation also used the Algolia JavaScript SDK, Algolia Golang SDK, background job processing, and the platform’s existing microservices and operational databases.
Results
The Algolia implementation changed the platform’s search flow from distributed real-time aggregation to indexed product discovery.
Faster Search Responses
Catalogue searches no longer depended on retrieving and combining data from several microservices for every query. The search page could request a prepared, search-optimised product representation directly from Algolia. This reduced the number of internal calls required to present results and made the interface feel more immediate.
Reduced Load on Core Services
Search and filtering traffic was moved away from operational databases and transactional microservices. The existing services continued to manage authoritative product and booking data, while Algolia handled read-heavy discovery operations. This separation reduced the risk that a high volume of catalogue searches would interfere with product management, availability processing, or booking-related workflows.
More Powerful Product Filtering
Users could combine multiple filters and progressively narrow the catalogue without forcing the platform to construct expensive queries across several systems. Faceted navigation also created a clearer discovery journey because the interface could present relevant filter values based on the available result set.
Improved Search Data Consistency
Background synchronisation kept search records aligned with changes made in the source microservices. Because indexing was handled asynchronously, the platform could apply retries and track failures without delaying normal product-management operations.
Better Scalability Across Partner Sites
The search layer provided a reusable model for supporting multiple partner catalogues. Partner-site identifiers and filterable attributes allowed the platform to use a consistent search architecture while presenting different product selections and filtering experiences to different websites.
Foundation for Future Search Improvements
The new search architecture created a strong foundation for future improvements. The client can use search analytics to understand what customers are looking for, which searches return poor results, and which products receive the most engagement.
The platform can also introduce synonyms to improve matching between different search terms, customised ranking rules to promote relevant products, query suggestions to help users complete searches, and popularity-based ranking to prioritise frequently viewed or booked products.
In the future, the client could also explore personalized search results based on user behaviour, location-based product discovery, and controlled search experiments to compare different ranking rules, filters, or result layouts.
Measurement Note
The available project information confirms that the implementation improved search responsiveness, reduced load on operational services, supported stronger filtering, and created a more scalable search process. However, validated before-and-after performance figures were not available, so the case study does not include unsupported claims about exact response-time improvements, conversion increases, or cost savings.
To measure the long-term impact of the solution, the client should track indicators such as average and p95 search response time, search-to-product click rate, search exit rate, zero-result searches, filter usage, product views generated through search, index synchronisation delay, failed indexing jobs, and the overall cost of search and indexing operations.
Key Learnings
The search index should be designed around how users search, filter, and view products rather than simply copying the structure of the operational databases. A search-focused data model makes records easier to manage and helps the platform return useful results more efficiently.
A dedicated search platform can reduce the dependency between catalogue discovery and transactional microservices. However, this only works effectively when the data synchronisation process is treated as an important production component with proper monitoring, retries, and recovery mechanisms.
Multilingual support should be planned during the initial index design. Simply adding translated fields without considering ranking rules, language settings, record duplication, and indexing cost can lead to inconsistent search behaviour.
Only attributes that genuinely improve product discovery should be configured as facets. Adding too many facets can increase index size, cost, and configuration complexity without providing meaningful value to users.
Background jobs must be designed to handle failures safely. Retries, idempotency, monitoring, and recovery processes are essential to prevent the Algolia index from becoming inconsistent with the source systems.
A managed search service can reduce implementation time and operational effort, but it still requires proper governance. Teams must carefully manage record size, indexing operations, credentials, environment separation, and search relevance settings.
Future Outlook
Search Analytics and Relevance Tuning
Search analytics can help the client understand how customers interact with the catalogue. It can show which queries lead to product clicks, which searches return no results, and where users repeatedly change or remove filters.
These insights can be used to improve synonyms, searchable product fields, ranking priorities, category names, product metadata, and the placement of filters on the search page. Over time, this can make the search experience more relevant and easier to use.
Personalised Product Discovery
Future versions of the platform could adjust product rankings using customer context, destination interests, previous search behaviour, or partner-site configuration.
Personalisation should be introduced carefully. The system should continue showing a broad and relevant range of products instead of hiding useful options based only on past behaviour.
Geographic Search
Travel and activity products are strongly connected to location. By adding geographic coordinates to product records, the platform could support searches for activities near a hotel, experiences within a particular area, or products close to the customer’s current location.
This could make product discovery more practical for travellers who want to explore nearby attractions and activities.
Search Experimentation
The platform could test different ranking strategies, filter arrangements, product-card designs, and query suggestions to understand which combinations improve product discovery and booking engagement. These experiments should be measured using real search behaviour, such as product clicks, zero-result searches, filter usage, and movement from search results to product pages.
Stronger Index Consistency Controls
As the platform grows and more microservices contribute product information, the synchronisation process may require stronger consistency controls. Future improvements could include event versioning to prevent older updates from replacing newer data, dead-letter queues for failed jobs, scheduled reconciliation between source systems and Algolia, and automated checks to identify missing or outdated records.
The team could also introduce zero-downtime index migrations and controlled index replacement strategies. These approaches would allow changes to the index structure or search configuration without interrupting the live catalogue experience.
FAQ
Why was Algolia selected instead of querying the existing databases?
The product data was distributed across several microservices and databases, so querying these systems directly required multiple network calls and added extra load to operational services. Algolia provided a dedicated, read-optimised search layer that could return prepared product records and apply advanced filters without repeatedly coordinating several services.
Why was Elasticsearch not selected?
Elasticsearch was considered because it provides powerful search capabilities and extensive customisation. However, the client needed a quicker implementation with less operational management. Algolia offered managed infrastructure, search APIs, faceting, filtering, and frontend integration without requiring the team to deploy, configure, monitor, and maintain a search cluster. The decision was based on delivery speed, available operational resources, and the required search features.
Did Algolia replace the existing product databases?
No, the existing databases remained the systems of record for all product and transactional information. Algolia stored only a search-optimised representation of product data for searching, filtering, ranking, and displaying catalogue results. Product administration, pricing, availability, supplier management, and booking workflows continued to operate through the original microservices and databases.
How did the search index stay updated?
Changes made within the source microservices were processed through background jobs. These jobs transformed operational product data into the required Algolia record structure and then created, updated, or deleted the corresponding search record. Failed operations could be logged and retried without delaying the original product update request.
How was multilingual content handled?
Translated product fields were included as part of the index design. Depending on relevance requirements, indexing costs, and partner-site configuration, the platform could store multiple languages within a shared index or use separate language-specific indices. Language settings were configured carefully because features such as plural handling, stop words, and typo tolerance can behave differently across languages.
How were advanced filters implemented?
Product fields required for catalogue refinement were configured as filterable or facetable attributes in Algolia. The Vue.js search page sent the selected filter combinations with each search request, and Algolia applied them directly within the index. This removed the need for the backend to collect and filter information from several microservices for every catalogue request.
What happens when Algolia is unavailable?
The application should handle an Algolia service failure by displaying a clear error message, recording the issue, and allowing the user to retry the search. A limited fallback search could also be introduced where required, but it should focus only on essential product discovery because maintaining two complete search systems would increase development and operational complexity.
How does the solution control indexing cost?
The index contains only the fields required for searching, filtering, ranking, and displaying results. Indexing costs can also be controlled through partial record updates, avoiding unnecessary facets, separating production and non-production environments, monitoring indexing operations, and carefully selecting whether multilingual content should use shared or separate indices.
