← Lessons

quiz vs the machine

Gold1380

System Design

The Timeline Cache

Keeping precomputed feeds in fast memory with bounded length and rebuild paths.

4 min read · core · beat Gold to climb

A feed lives in cache

In a push system, each user timeline is a list of post ids kept in a fast in memory store such as a key value cache. Reading the feed becomes a quick range read of that list rather than a database query.

The cache holds only ids, not full posts. The actual post content is fetched separately and joined in, so the timeline stays small.

Keeping it bounded

  • Each timeline is capped, often a few hundred to a few thousand recent ids. Older entries are trimmed.
  • A cap bounds memory and keeps reads fast, since nobody scrolls infinitely.
  • When a user scrolls past the cap, the system falls back to a slower store.

Rebuilding on miss

Caches are not durable, so a timeline can be evicted or lost. The system must rebuild it on demand by reading the user follow list and recent author posts, then refilling the cache. This rebuild path is also used for brand new users.

Why it matters

The timeline cache is what turns a feed open into a single fast lookup. Without it, every read would re scan author posts.

Key idea

The timeline cache stores a bounded list of recent post ids per user in fast memory, with a rebuild path from the follow graph when it is missing.

Check yourself

Answer to earn rating on the learn ladder.

1. What does a timeline cache typically store?

2. Why are timelines capped in length?

3. Why must the system support rebuilding a timeline?