Design the backend service that stores and serves the follow graph for a large consumer social product (think a popular short-video app). Every user can follow other users; the resulting directed edges drive who appears in feeds, whose posts are eligible for fan-out, and the follower/following counts shown on every profile. Your service owns those edges and the reads/writes on top of them — nothing else.

Operating context. ~600M registered accounts and ~250M daily actives. The graph holds ~150B directed edges and grows by tens of millions of new edges per day. Read traffic is heavy and bursty: ~400k QPS of edge/count/relationship-state reads at peak, versus ~30k QPS of writes (follow, unfollow, block, mute). The distribution is brutally skewed — the top ~10k accounts (celebrities, brands) each have tens of millions of followers, while the median account has fewer than 300. A single celebrity follow event can be read by millions of clients within seconds. Reads must feel instant (p99 ≤ 40 ms server-side); a freshly created follow edge should be visible to the actor's own next read immediately, but a globally correct follower count may lag by a few seconds.

Out of scope. Do not design the feed ranking or feed delivery pipeline, the post/media storage, the notification system, or account authentication. Assume identity and abuse-scoring services already exist and expose synchronous APIs.

What to produce. Sketch the components and the request/response path for the core operations: follow(a→b), unfollow(a→b), block/mute, isFollowing(a,b), listFollowers(b), listFollowing(a), and getCounts(u). Define the data model and how you shard it, how you maintain a reverse index so both "who follows me" and "who I follow" are cheap, how you handle hot nodes (celebrity followers), how follower/following counts stay correct under high write concurrency, and how block/mute edges interact with follow reads. Call out the consistency guarantees per operation and the main failure modes.