Common Social-Media Design Patterns
High Level Design·advanced·~45 min read
- system-design
- social-media
- follower-followee
- sharding
- feed
- bloom-filter
- hld
- 1. The Follower / Followee Entity Problem - 2. The Celebrity Problem — Hot Partitions - 3. The Follow / Unfollow Button - 4. Mutual Followers ("Followed by Alice and 3 others") - 5. The Home Feed — Fan-Out - What to Say in an Interview…
What you'll learn
1. The Follower / Followee Entity Problem
You want to store (followerId, followeeId, sinceWhen) and satisfy two access patterns: - By followerId — "Who is Alice following?" - By followeeId — "Who follows Alice?" A relational DB solves this with two indexes and calls it a day. In…
1a. Global Secondary Index / Materialized View
Keep one base table for the primary query. The database transparently maintains a second index for the reverse query. | Table | Partition Key | Sort Key | Answers | |--------|---------------|-------------|-----------------------------| |…
5e. Feed-Store Retention — Keep the Inbox Tiny
A normal user with 500 followers times 5 posts/day times 10 years = 9 M post IDs in their inbox. Nobody scrolls to year 9. Treat the fanned-out feed as a temporary materialised view, not an archive. Cap it in one of two ways (industry pi…
5f. Deep-Scroll Fallback — Reuse the Celebrity Pull Path
User swipes past the 500th post. You already have the mechanism for this: the pull model you built for celebrities. 1. Client sends GET /feed?before= for data older than retention. 2. Feed Service recognises the cursor is past the inbox…
5g. Search Doesn't Use the Feed
Search ignores the feed store entirely — it needs an inverted index, not a chronological list. - When a post is written, an async event fans it to a search cluster (Elasticsearch / Solr / OpenSearch). - The search cluster indexes body te…
5h. Feed-Cache Data Structure — Redis Sorted Set
Rule 0: never store post bodies in the feed cache. Store only userId → [list of post IDs]. When the client requests the feed, hydrate the IDs via a separate Post Object Cache (also Redis, keyed by post:{id}). This avoids: - Duplicating a…
5i. Feed DB vs Post DB — Different Workloads, Different Choices
| System | Load | Right choice | Why | |-------------|----------------------------------|-------------------------------------|---------------------------------------------------------------------| | Feed DB | Fan-out writes dominate (on…
What to Say in an Interview
1. Denormalise for two-sided reads. GSI, dual-table, or single-table adjacency-list — pick one and defend the trade-off. 2. Random-shard the celebrity's inbound edges and store shardCount on their profile row. 3. Deterministic-shard outb…