Overview
S-Parking implements a dual-layer real-time monitoring system that combines Firestore’s native real-time capabilities with intelligent client-side optimizations. This architecture ensures users always see current parking availability while minimizing API costs and battery consumption.Architecture
Firestore Listeners
Server-side real-time updates via Cloud Functions that automatically expire reservations
Client Polling
Smart polling with adaptive intervals and Page Visibility API integration
Data Flow
Polling Implementation
The dashboard uses configurable polling intervals with built-in caching to reduce load:Cache Duration: Default 15 seconds (configurable via
CONFIG.PERFORMANCE.CACHE_PARKING_STATUS)Automatic Reservation Expiration
The Cloud Function automatically releases expired reservations when serving status requests:Why Server-Side Expiration?
Why Server-Side Expiration?
By handling expiration in the Cloud Function that serves parking status, we ensure:
- Zero client logic needed for expiration
- Atomic updates via Firestore batch operations
- Immediate visibility of freed spots without additional polling
- Cost efficiency by piggybacking on existing status requests
Page Visibility API Optimization
S-Parking pauses all polling when the browser tab is hidden, saving battery and reducing costs:Battery Savings: On mobile devices, pausing background polling can reduce battery consumption by up to 40%
Polling Intervals
S-Parking uses three separate polling loops with different frequencies:| Interval Type | Default | Purpose |
|---|---|---|
| Data Polling | 20s | Fetch parking spot status |
| Timer Update | 5s | Update relative timestamps (“2 min ago”) |
| History Refresh | 10m | Fetch occupancy snapshots for charts |
Cache Invalidation
The cache is automatically invalidated after mutations to ensure consistency:Cache Invalidation Triggers
Cache Invalidation Triggers
- Creating a parking spot
- Updating spot details (location, zone, description)
- Deleting a spot
- Making a reservation
- Releasing a reservation
Fallback Strategy
When the API is unreachable, S-Parking falls back to localStorage:Offline Mode
Dashboard continues working with cached data when disconnected
Sync on Reconnect
Automatically fetches latest data when connection is restored
Performance Metrics
Real-World Performance (measured on DUOC UC deployment):
- API response time: ~200ms (p95)
- Cache hit rate: ~65% during normal operation
- Data freshness: < 20 seconds guaranteed
- Battery impact: < 2%/hour on mobile devices
Best Practices
Configuring Polling Intervals
Configuring Polling Intervals
Adjust intervals based on your usage patterns:
Monitoring API Costs
Monitoring API Costs
Track your Firestore reads to optimize costs:
- Enable Firestore monitoring in Google Cloud Console
- Set up billing alerts at 80% threshold
- Use longer cache durations during low-traffic periods
- Consider scheduled polling (e.g., only during business hours)
Handling Network Failures
Handling Network Failures
The fallback system handles failures gracefully:
- First failure: Return cached data (15s old maximum)
- Cache expired: Use localStorage (last successful fetch)
- No localStorage: Show error message with retry button
Related Topics
Reservation System
Learn how reservations integrate with real-time updates
Analytics Dashboard
Historical data collection via hourly snapshots