Real-Time Search Infrastructure at Scale

Building sub-500ms city-wide vehicle search with dynamic geographic expansion and real-time availability filtering

Search infrastructure in real-time marketplaces faces a unique challenge: provide instant, accurate results across thousands of dynamic inventory items while maintaining strict performance constraints. When users search for vehicles, they expect immediate responses with current availability—no stale data, no false positives, no delays.

This is the technical story of a search system that delivers sub-500ms response times for city-wide vehicle searches, combining geographic indexing, real-time availability filtering, and intelligent result ranking under extreme performance pressure.

The Real-Time Search Challenge

Building search infrastructure for marketplace inventory requires solving multiple technical problems simultaneously while meeting unforgiving performance requirements.

Performance Requirements: Sub-500ms response time for city-wide searches across thousands of vehicles with real-time availability, geographic filtering, and personalized ranking.

Core Technical Constraints:

Response Time: 500ms maximum for complete search results including pagination
Data Freshness: Real-time availability accuracy—no stale inventory data acceptable
Geographic Scale: City-wide search radius with intelligent boundary expansion
Complex Filtering: Time-based availability, location proximity, vehicle attributes
Result Quality: Personalized ranking integrated without performance degradation

Why Traditional Search Engines Don't Work

Standard search solutions like Elasticsearch or Solr struggle with the real-time inventory problem:

Index Lag: Document indexing delays mean showing unavailable vehicles
Update Overhead: Constant availability changes create excessive index churn
Consistency Issues: Distributed search indexes struggle with real-time consistency
Performance Trade-offs: Rich search features often sacrifice response time

Key Insight: "This is not social media" - Vehicle availability is binary and critical. Unlike social feeds where stale data is acceptable, showing unavailable cars destroys user experience and wastes time.

Geographic Circle Expansion Architecture

The search system employs a dynamic geographic expansion strategy that starts with high-relevance local results and intelligently expands the search radius until sufficient results are found.

Intelligent Radius Expansion Algorithm

Rather than using fixed radius increments, the system employs city-specific expansion patterns based on geographic understanding and vehicle density:

Geographic Expansion Strategy: 1. Start with initial radius based on search location type (city center vs suburbs) 2. Use city-specific expansion pattern: 2km → 5km → 20km → city-wide 3. At each radius level: - Query Redis GEORADIUS for vehicles within distance - Batch check availability for all found vehicles - Apply personalization ranking to available vehicles - Return results if pagination requirements met 4. If insufficient results, expand to next radius level 5. Continue until target result count achieved or maximum radius reached

City-Specific Configuration

Different cities require different expansion strategies based on vehicle density, geographic constraints, and urban layout:

City Configuration Examples: Mumbai (High Density): - Initial: 1km → 3km → 8km → 15km - Dense urban environment with short travel distances Bangalore (Medium Density): - Initial: 2km → 5km → 12km → 25km - Balanced urban/suburban with moderate vehicle spread Delhi NCR (Large Metro): - Initial: 3km → 8km → 20km → 50km - Extended metropolitan area requiring larger search radii

Optimization Insight: City-specific expansion patterns reduce unnecessary geographic queries while ensuring comprehensive coverage based on local market characteristics.

Redis-Based Geographic Indexing

The system leverages Redis geospatial capabilities for high-performance geographic queries while maintaining real-time data consistency.

Geospatial Data Structure

Vehicle locations are stored in Redis using geospatial indexing that enables efficient radius-based queries:

Redis Geospatial Architecture: • Primary Index: GEOADD city:{city_id}:vehicles {lng} {lat} {vehicle_id} • City-level partitioning for performance and geographic isolation • Real-time updates as vehicles move or change status • GEORADIUS queries for circle-based search with distance sorting Query Performance: • GEORADIUS operations: O(N+log(M)) where N=results, M=total vehicles • Typical query time: 5-15ms for city-wide geographic filtering • Memory efficient: ~50 bytes per vehicle for geospatial data

Batch Availability Verification

After identifying geographically relevant vehicles, the system performs batch availability checks to minimize Redis round trips:

Batch Availability Check Process: 1. GEORADIUS returns list of vehicle_ids within current search radius 2. Construct batch availability query: HMGET availability:cache {vehicle_ids...} 3. Filter results for time-based availability using start/end time parameters 4. Return only vehicles available for requested booking period Optimization Benefits: • Single Redis call for all availability checks within radius • Reduced network latency through batching • Consistent availability data from centralized cache

Real-Time Availability Integration

The search system integrates directly with the inventory management system to ensure absolute real-time accuracy in availability data.

Availability Cache Architecture

Design Principle: Search system queries the same Redis infrastructure used by the inventory management system, ensuring perfect consistency between search results and actual availability.

SEARCH-INVENTORY INTEGRATION INVENTORY UPDATES +----------------+ +----------------+ +----------------+ +----------------+ | Booking |--->| Inventory |--->| Redis |--->| Availability | | Events | | Management | | Updates | | Cache | +----------------+ +----------------+ +----------------+ +----------------+ | | | | SEARCH QUERIES | | +----------------+ +----------------+ +----------------+ +----------------+ | User Search |--->| Geographic |--->| Batch |<---| Real-time | | Request | | Filtering | | Availability | | Consistency | +----------------+ +----------------+ +----------------+ +----------------+

Time-Based Availability Logic

Vehicle availability is not just binary—it depends on the requested booking time window. The system efficiently handles complex time-based availability calculations:

Time-Based Availability Algorithm: 1. For each vehicle in geographic results: - Retrieve current booking schedule from Redis - Check for conflicts with requested [start_time, end_time] - Validate against maintenance/blocking schedules - Apply buffer time requirements (cleaning, handover) 2. Availability States: - AVAILABLE: No conflicts in requested time window - PARTIALLY_AVAILABLE: Available but with time restrictions - UNAVAILABLE: Conflicts exist in requested window 3. Only AVAILABLE vehicles included in search results

Performance Optimization Strategies

Achieving sub-500ms response times requires aggressive optimization at every system layer.

Query Path Optimization

Performance Optimization Techniques: • Redis Connection Pooling: Minimize connection overhead • Batch Operations: Single Redis call for multiple lookups • Early Termination: Stop radius expansion once pagination filled • Parallel Processing: Concurrent availability checks within radius • Memory Caching: JVM-level caching for city configurations • Query Optimization: Minimize Redis operations per search request Typical Performance Breakdown: • Geographic query (GEORADIUS): 10-20ms • Batch availability check: 15-30ms • Recommendation ranking: 20-40ms • Result formatting/pagination: 5-10ms • Network/serialization: 10-20ms • Total: 60-120ms (well under 500ms budget)

Connection and Memory Management

High-performance search requires careful resource management:

Resource Optimization: • Redis Connection Pool: 50-100 connections per instance • JVM Heap Tuning: Optimized for high-frequency allocations • Object Pooling: Reuse search result objects to reduce GC pressure • Async Processing: Non-blocking I/O for Redis operations • Memory Monitoring: Real-time tracking of allocation patterns

Recommendation Integration

The search system integrates personalized recommendations without compromising performance by leveraging pre-computed recommendation scores.

Pre-computed Recommendation Strategy

Performance Trade-off: Rather than computing recommendations in real-time (too slow), the system applies pre-computed recommendation scores to search results during the ranking phase.

Recommendation Integration Process: 1. Search identifies available vehicles within geographic constraints 2. Retrieve pre-computed recommendation scores for current user 3. Apply recommendation ranking to available vehicle set 4. Sort results by combined relevance score (availability + recommendation + proximity) 5. Return top results with pagination Ranking Formula: final_score = (availability_score * 0.4) + (recommendation_score * 0.3) + (proximity_score * 0.2) + (recency_score * 0.1)

Dynamic Ranking Adjustments

The system applies real-time ranking adjustments based on search context:

Proximity Weighting: Closer vehicles receive higher ranking scores
Availability Confidence: Vehicles with longer availability windows ranked higher
User Preference Matching: Vehicle attributes aligned with user history
Temporal Relevance: Recent vehicle additions or updates boosted in ranking

Pagination and Result Management

Efficient pagination in geographic search requires careful balance between performance and user experience.

Dynamic Result Loading

Pagination Strategy: • Page Size: 20 vehicles per page (optimized for mobile/desktop) • Expansion Logic: Continue radius expansion until 40+ results found • Result Buffering: Cache additional results for subsequent page requests • Stable Sorting: Consistent ranking across pagination requests • Deep Pagination: Limit to 10 pages (200 vehicles) for performance Performance Optimization: • Stop radius expansion early if sufficient results found • Cache expanded results for faster subsequent pages • Use cursor-based pagination for large result sets

City-Wide Search Architecture

Error Handling and Fallback Strategies

Real-time search systems require robust error handling to maintain service availability under various failure conditions.

Graceful Degradation

Fallback Strategy Hierarchy: 1. Primary: Real-time Redis search with full features 2. Degraded: Cached results with availability warnings 3. Minimal: Static vehicle list without personalization 4. Emergency: City-wide inventory dump with basic filtering Error Scenarios: • Redis connection failure: Fall back to database queries • Timeout exceeded: Return partial results with continuation token • Geographic service unavailable: Expand to city-wide search • Recommendation service down: Return results without personalization

Performance Monitoring and Alerting

SLA Monitoring: Real-time tracking of search performance with immediate alerting when response times exceed 400ms (80% of SLA budget).

Response Time Tracking: P50, P95, P99 latency monitoring across all search operations
Availability Monitoring: Success rate and error classification for search requests
Geographic Performance: Per-city performance analysis to identify regional issues
Resource Utilization: Redis connection pool usage, memory allocation patterns

Performance Results and Business Impact

Performance Achievement: Consistent sub-500ms response times for city-wide vehicle searches while maintaining 100% real-time availability accuracy across all markets.

System Performance Metrics:

Response Time: P95 latency under 300ms, P99 under 450ms
Availability Accuracy: Zero false positives in search results (no unavailable vehicles shown)
Geographic Coverage: Complete city-wide search capability with intelligent boundary expansion
Throughput: Handle 10K+ concurrent search requests during peak periods

Business Impact:

User Experience: Instant search results improved customer satisfaction and booking conversion
Inventory Utilization: Accurate availability display maximized vehicle utilization rates
Operational Efficiency: Real-time accuracy eliminated customer service issues from stale search data
Scalability: System architecture scaled across 25+ cities without performance degradation

Key Engineering Insights

Real-time accuracy trumps caching in critical applications: For inventory-based searches, showing stale data causes more problems than potential performance gains from caching.

Geographic intelligence enables performance optimization: City-specific radius expansion patterns significantly reduce unnecessary queries while ensuring comprehensive coverage.

Batch operations are crucial for sub-second performance: Minimizing Redis round trips through intelligent batching enables meeting strict performance requirements.

Evolution and Future Enhancements

Predictive Availability: Future systems could incorporate machine learning to predict vehicle availability patterns and pre-compute search results for common queries.

Advanced Geographic Intelligence: Integration with traffic data and route optimization could enhance proximity calculations and travel time accuracy.

Real-time Personalization: As computational resources increase, the system could move toward real-time recommendation computation during search execution.

← Back to All Writing