Search performance transformed from 20 seconds to under 2 seconds

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.

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.

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

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:

1. Application cache: Recently searched result sets cached in memory
2. Query cache: Common filter combinations cached with appropriate TTL
3. 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.