Skip to main content
In this lesson we cover the final step of our feed design framework: identifying bottlenecks and planning for scale. For a precomputed feed architecture the two caches are the most important components — they keep latency low and make feed reads fast. Below we identify those caches, estimate their size, and discuss database choices and sharding strategies.

​
The two caches: what they store and why they matter

​
Cache 1 — Per-user feed lists (IDs)

  • Purpose: store a precomputed, bounded list of post IDs per active user (the feed list).
  • Typical list size: store up to 500 post IDs per user.
  • ID size: approximately 8 bytes per post ID.
Sizing example:
  • 500 post IDs × 8 bytes = 4,000 bytes ≈ 4 KB per user.
  • For 10,000,000 active users: 4 KB × 10,000,000 = 40 GB (estimate; overhead and metadata will increase this).
Cache 1 is primarily keyed by user and optimized for fast reads of the feed list (IDs only).

​
Cache 2 — Post content cache (payloads)

  • Purpose: cache the actual post payloads (text, media pointers, metadata) so the app server can fetch content quickly after reading the per-user ID list.
  • Example activity: if each active user posts on average 3 times per month, and there are 10M active users:
    • 3 × 10,000,000 = 30,000,000 posts per month.
  • If each post payload averages ~1 KB:
    • 30,000,000 × 1 KB ≈ 30 GB for one month of posts.
In practice Cache 2 is sized to hold the “hot” subset of posts and uses eviction policies like LRU (Least Recently Used) to keep new and popular posts in memory.

​
Quick sizing summary

A dark-themed system architecture diagram titled "Active Users Only" showing a feed architecture with Redis feed and post caches, an app server, database tables, and a background job queue with worker nodes. It visualizes how user feeds and posts flow between mobile clients, caches, and backend components.

​
Active users only

  • We typically only precompute feed lists for active users — for example, users who opened the app in the last 30 days (configurable).
  • Avoid pushing updates into feed lists for users who haven’t used the app in months; this work is likely wasted and consumes cache capacity.
  • If an inactive user returns, build their feed on read (generate the list when they open the app) rather than continuously updating their list while they are inactive.
Sizing numbers above are order-of-magnitude estimates to reason about capacity. In production measure actual post sizes, access patterns, and add overhead factors for cache metadata, replication, and other inefficiencies.

​
Database considerations: choose technology by data shape

Different tables and access patterns map better to different storage systems. Growth and sharding
  • At ~30M posts/month → ~360M posts/year. This growth requires planning for distributed storage.
  • One machine cannot hold all posts at scale. Partition (shard) posts across multiple machines and design for rebalancing, replication, and index distribution.
  • Consider read/write patterns, hotspots, and the cost of cross-shard joins when selecting a sharding key.

​
Summary / operational checklist

  • Two caches are central:
    • Per-user feed lists (IDs): small, per-user, low-latency read.
    • Post content cache: holds payloads for hot reads; eviction (LRU) keeps memory bounded.
  • Precompute lists only for active users to reduce wasted work and storage.
  • Choose database technologies based on data shape (append-only vs relational) and plan for sharding/storage growth.
  • Monitor actual post sizes, request patterns, cache hit rates, and re-evaluate cache sizing and eviction policies regularly.
Further reading and references:

Watch Video