Design a Follower-Following System

Problem statement

Design a follower-following system for a large social platform: users follow and unfollow other users; the platform maintains a directed relationship graph; it serves followers and following lists quickly; it exposes accurate-enough counts; and it honors privacy through private accounts and blocks. Although the brief looks simple—two buttons and two lists—every feed, notification, mention, recommendation, and ranking model downstream consumes this graph, so it becomes one of the most read-heavy and skew-heavy data structures in the platform.

The core object is a directed edge (followerId -> followeeId) with metadata: created_at, status (active, requested, rejected, removed), and origin. From this one edge table we must derive: the following list (out-edges), the followers list (in-edges), two monotonic-ish counts, existence checks (do I follow X?), mutual-friend intersections, candidate generation for suggestions, and fan-out triggers for timelines. The asymmetry is the design driver: out-edges per user are bounded (a few thousand), while in-edges per user are unbounded (hundreds of millions for celebrities). Any naive single-index design dies on the in-edge side.

Why this is a distinctive system-design question

A follow system combines four hard problems at once: (1) a write path that must be transactional and idempotent (no duplicate edges, no double unfollow side effects) while simultaneously triggering asynchronous fan-out; (2) a read path dominated by hot keys—celebrity follower lists and counts—requiring cache architecture that survives stampedes; (3) a graph query surface (lists, counts, existence, mutuals, 2-hop candidates) that demands purpose-built indexing rather than a general-purpose schema; and (4) privacy semantics (private accounts, blocks) that must be enforced on every read path without turning the cache into a correctness liability.

Public operating baseline versus design assumptions

Public evidence shows the category's scale. Twitter publicly reported around 500 million tweets per day and roughly 238 million monetizable daily active users in 2022 shareholder material; its follow graph powers timeline fan-out. Facebook's TAO paper (USENIX ATC 2013) describes a distributed social-graph store serving a read-to-write workload skewed on the order of a thousand reads per write with very high cache hit rates. Instagram's engineering blog described fan-out-on-write into Redis timelines with sharded Postgres for the graph. LinkedIn published its People-You-May-Know graph-ranking approach over a 1-billion-member graph. These are cited company signals, not our requirements.

For capacity planning this answer explicitly assumes: 500 million registered users, 150 million DAU, 80 billion active follow edges, 300 million follow/unfollow writes per day, and a 10x peak multiplier on reads during breaking-news events. Unless cited, every number is a stated assumption.

The four architectural planes

1. Edge plane: transactional graph store with dual indexing (out-edges and in-edges), block and private metadata, and idempotent writes.
2. Read plane: follower/following list service, count service, and existence checks backed by a multi-tier cache.
3. Propagation plane: follow events fanned out to timeline builders, notification services, and suggestion pipelines.
4. Intelligence plane: offline and near-real-time candidate generation (triangle closing, 2-hop traversal) plus ranking for follow suggestions.

A strong interview answer keeps these planes separate: the edge plane is CP and boring; the read plane is AP with explicit freshness; the propagation plane is eventually consistent by design; and the intelligence plane tolerates minutes of staleness.