This document outlines the caching system implemented for high-traffic components in our Next.js application.
- SWR + localStorage: Implemented a hybrid caching approach using SWR for data fetching with stale-while-revalidate pattern and localStorage for offline access.
- Cache Invalidation: Automatic and manual cache invalidation mechanisms to ensure data consistency.
- Optimistic Updates: Immediate UI updates with background synchronization for better user experience.
lib/cache/notificationsCache.ts: Core caching utilities for notificationslib/hooks/useNotifications.ts: Custom hook for notifications data with cachinglib/hooks/useUnreadNotifications.ts: Custom hook for unread notifications countcomponents/NotificationsMain.tsx: Updated component using the caching system
- Reduced API Calls: Minimizes redundant API calls by using cached data when available
- Offline Support: Basic functionality when offline through localStorage
- Improved Performance: Faster UI rendering with cached data
- Better UX: Optimistic updates for immediate feedback
- IndexedDB for Message Caching: Persistent storage for chat messages using IndexedDB
- Socket Connection Manager: Robust socket connection handling with reconnection logic
- Offline Message Queue: Store and retry mechanism for messages sent while offline
- Fallback Mechanisms: Redundant API calls for critical operations
lib/cache/chatCache.ts: IndexedDB-based cache for chat messages and metadatalib/socket/socketManager.ts: Socket connection management with reconnection logiclib/hooks/useChat.ts: Custom hook for product chat functionalitylib/hooks/useSupportChat.ts: Custom hook for support chat functionality
- Connection Resilience: Robust handling of network interruptions
- Offline Support: Queue messages when offline for later delivery
- Reduced Data Transfer: Only fetch new messages instead of entire chat history
- Improved Reliability: Fallback mechanisms ensure message delivery
- Redis Caching: Server-side caching of analytics data using Redis
- Time-based Invalidation: Automatic cache expiration based on data type
- Selective Invalidation: Targeted cache invalidation when data changes
- Client-side Cache: Additional browser-side caching for frequently accessed data
lib/redis/redisClient.ts: Redis client configurationlib/redis/analyticsCache.ts: Redis-based caching utilities for analyticsapp/api/user/analytics/route.ts: API route with Redis cachingapp/api/ads/[id]/analytics/route.ts: Ad analytics with cache invalidationlib/hooks/useAnalytics.ts: Custom hook with client-side caching
- Reduced Database Load: Minimizes expensive analytics queries
- Faster API Responses: Pre-computed analytics data served from cache
- Scalability: Better handling of traffic spikes with cached responses
- Real-time Updates: Selective cache invalidation ensures fresh data
- Faster Page Loads: Initial page loads are significantly faster with cached data
- Reduced Time-to-Interactive: UI becomes interactive more quickly
- Smoother User Experience: Less waiting for data fetching operations
- Fewer Database Queries: Cached data reduces the need for database access
- Lower API Traffic: Reduced number of API calls through client-side caching
- More Efficient Resource Usage: Server resources are used more efficiently
- Graceful Degradation: Application remains functional during network issues
- Consistent Experience: Users experience fewer disruptions during connectivity problems
- Error Recovery: Automatic retry mechanisms for failed operations
- Better Peak Handling: System can handle traffic spikes more effectively
- Reduced Infrastructure Needs: Lower resource requirements for the same user load
- Cost Efficiency: Reduced server costs through more efficient resource utilization
- Server-side caching in API routes using Redis
- Middleware for cache control and invalidation
- Custom hooks for data fetching with caching logic
- Integration with SWR for stale-while-revalidate pattern
- Components updated to use cached data
- Optimistic UI updates for better user experience
- Time-based Expiration: Automatic expiration of cached data
- Event-based Invalidation: Cache invalidation on specific events (e.g., new message)
- Selective Updates: Partial cache updates for changed data
- Background synchronization of cached data with server
- Conflict resolution for concurrent updates
- Graceful degradation during network issues
- Automatic retry mechanisms with exponential backoff
- Fallback to API calls when cache is empty or invalid
- Loading states during cache misses
- Validation of cached data before use
- Refresh mechanisms for stale data
{
"@upstash/redis": "^1.20.6",
"idb": "^7.1.1",
"swr": "^2.2.0"
}- Redis connection configuration in environment variables
- Cache expiration times configurable per data type
- Service Worker integration for more robust offline support
- Shared worker for cross-tab synchronization
- More sophisticated conflict resolution strategies
- Analytics for cache hit/miss rates
- Regular monitoring of cache size and performance
- Periodic review of cache invalidation strategies
- Adjustment of cache expiration times based on usage patterns