Search Performance Transformed from 20 Seconds to Under 2 Seconds
How architectural optimisation delivered 90% faster search results for caravan holiday seekers
Industry:Travel & Logistics Solutions
Key results at a glance
The challenge
The problem
Holiday Caravans Direct's booking platform had a critical user experience issue: searching for available caravans took 10-20 seconds to return results. In a world where users expect instant responses, this was causing visitors to abandon searches before seeing results.
The search functionality was the heart of the platform. Users came to find available caravans matching their criteria - dates, location, size, budget. If this core experience was slow, the entire business suffered.
The complexity
The slow performance was not a simple bug to fix. The search had to:
- Query availability across thousands of caravans
- Check multiple date ranges against booking calendars
- Filter by numerous criteria (location, size, amenities, price)
- Return results sorted by relevance
- Handle peak traffic during booking seasons
The existing implementation had grown organically as the platform added features, and what worked with a small inventory no longer scaled with 5,000 caravans.
The results
Key results
- Search response time reduced from 10-20 seconds to 1-2 seconds
- 90% performance improvement across 5,000 caravan dataset
- Consistent performance maintained during peak booking periods
- Sustainable architecture that scales with inventory growth
- Reduced user abandonment during search process
Performance transformation
- Search time reduced from 10-20 seconds to 1-2 seconds (90%+ improvement)
- Consistent performance across the full dataset of 5,000 caravans
- Reliable response times even during peak traffic periods
User experience impact
- Users no longer abandoned searches while waiting for results
- Search became a seamless part of the booking journey
- Platform could handle higher traffic without degradation
Technical sustainability
- New indexing and caching strategies documented for the team
- Query patterns established as templates for future development
- Performance monitoring in place to catch any future regressions
The solution
Our approach
Rather than applying quick fixes, we conducted a thorough architectural analysis to understand why the search was slow and what would sustainably improve it.
Root cause analysis
We profiled the search functionality and identified several compounding issues:
- Multiple database queries executing sequentially rather than in parallel
- Inefficient query patterns that retrieved more data than needed
- Missing or suboptimal database indexes for common search filters
- Availability calculations repeated for each search rather than cached
- No query result caching for common search combinations
Architectural improvements
We redesigned the search architecture with performance as the primary concern:
Query optimisation
- Rewrote search queries to retrieve only necessary data
- Combined multiple queries into efficient single operations where possible
- Added targeted indexes for the most common search patterns
Caching strategy
- Implemented caching for availability data that changed infrequently
- Cached common search result combinations
- Added intelligent cache invalidation when bookings were made
Parallelisation
- Restructured code to execute independent operations in parallel
- Reduced the critical path by running non-dependent queries simultaneously
Iterative improvement
We took a measured approach, implementing changes incrementally and measuring the impact of each optimisation. This allowed us to understand which changes delivered the most value and avoid introducing regressions.
Technical deep dive
Performance profiling approach
The first step was understanding where time was actually being spent. We instrumented the search path to measure:
- Database query execution times
- Data transformation and filtering logic
- Network round trips
- Response serialisation
This revealed that the problem was not any single slow operation, but rather many moderately slow operations compounding together.
Database optimisation details
The biggest wins came from database-level improvements:
Index strategy: We analysed the most common search patterns (date range, location, size) and ensured composite indexes existed for these combinations. A search for "3-bedroom caravans in Cornwall available in August" could now use a single index scan rather than multiple table scans.
Query rewriting: Original queries often retrieved full caravan records when only summary information was needed. By selecting only required columns and using appropriate projections, we significantly reduced data transfer.
Availability pre-computation: Rather than calculating availability for every caravan on every search, we implemented a denormalised availability summary that could be queried efficiently.
Caching architecture
We implemented a tiered caching strategy:
- Application cache: Recently searched result sets cached in memory
- Query cache: Common filter combinations cached with appropriate TTL
- Availability cache: Pre-computed availability windows updated on booking changes
Cache invalidation was carefully designed so that new bookings immediately reflected in search results without requiring full cache clears.
Lessons for similar projects
The key insight from this project: dramatic performance improvements often come from architectural changes rather than code optimisation. The original code was not poorly written - it had simply evolved without performance as a primary design constraint. By stepping back and redesigning the search architecture, we achieved improvements that would have been impossible through incremental code tweaks.
Ready to achieve similar results?
Let's discuss how we can help your organisation achieve these results.
Book a strategy call