STANDARDwalkthrough
Cache Warming
A user opens the app after 8 hours of sleep. The constraint: their timeline cache was evicted overnight due to inactivity (Redis LRU eviction kicks in when memory pressure rises).
That cold-start penalty takes 500ms or more, compared to sub-10ms for a warm cache. Implication: if 50 million users open the app between 7 AM and 9 AM, we face a thundering herd of 50 million cold rebuilds in a 2-hour window, which would overwhelm our timeline mixer servers. Cache warming eliminates this by pre-building timelines before users request them.
“The first request triggers a full timeline rebuild: query the social graph for followed accounts, fetch recent posts from each, merge, rank, and cache.”
We implement three strategies, chosen based on user behavior patterns. The lazy strategy builds the cache on first request and lets subsequent reads benefit, accepting the one-time latency hit.
The eager strategy identifies users likely to open the app (based on DAU login patterns) and pre-builds their timelines during off-peak hours, typically between 4 AM and 6 AM local time. We chose eager warming for the top 20% most active users (not lazy) because they generate 80% of feed requests, and eliminating their cold starts reduces peak P99 latency by over 40%.
Trade-off: we gave up off-peak compute savings in exchange for consistent read latency during morning spikes. A third strategy handles celebrity posts specifically: when a celebrity publishes, we proactively pre-merge their post into the timeline caches of their most active followers, even though the celebrity uses fanout-on-read.
This hybrid warming ensures the most engaged users never experience a cold-start merge for popular content. What if the interviewer asks: 'How do we predict which users will open the app?' We train a lightweight model on login history: if a user has opened the app between 7-8 AM on 5 of the last 7 days, we warm their cache at 6:45 AM.
The model runs as a daily batch job, not in the hot path.
Related concepts