Social & feeds
The social graph - one edge, written twice
adjacency in both directions, follow against friend, and counters that drift
What this board gets wrong on purpose
The tension
A follow is two writes on two different shards with no transaction between them, and nothing on this board repairs a half-finished one. If the in-edge write fails after the out-edge succeeded, Alice follows Bob and Bob has no follower Alice: her timeline fills with his posts and his fan-out never sends him to her. The edge log is the only ordered record of what was intended and nothing consumes it to reconcile - it is drawn as a log, not as a repair loop, which is exactly the state most real systems are in. The counters are the same bug in miniature and visible to users: they are incremented off a queue, so a dropped message loses a follower forever, and they have never heard of blocks, which the read path filters out of the list at request time - so the number and the list disagree by design and there is no job that recomputes either.
Requirements
Clarifying questions to ask first
- Follow or friend, or both? A follow is one directed edge. A friendship is a request, a state machine and two edges. They are different systems and deserve different tables, not one table with a status column that is meaningless in half its rows.
- Are follower counts exact? If "approximately 2.1M" is acceptable, counters can be maintained asynchronously. If they must be exact, this becomes a much harder and much slower system.
- What is the maximum in-degree? An account with 100 million followers cannot have its follower list read into memory by anything, ever. Every consumer of that list must be a cursor.
- Do blocks hide an existing edge or delete it? Hiding preserves the edge and requires a filter on every read. Deleting is simpler and loses information the user may want back.
- Who consumes edge changes? Fan-out, notifications, recommendations and search all want to know. That answer decides whether there is a log at all.
- Must unfollow be immediate? It is the one operation users check by refreshing.
Functional
- Follow and unfollow another account; effective for the actor immediately.
- Send, accept and reject a friend request; an accepted request is a mutual pair of edges.
- Block an account: hide both directions, and prevent re-following.
- Answer does A follow B in single-digit milliseconds.
- List following(A) and followers(B), paginated with a cursor.
- Report follower and following counts.
Non-functional
- Edge existence check p99 under 5 ms. It is called on every profile view and inside fan-out.
- Follow write p99 under 100 ms as seen by the actor.
- 99.99% availability on edge reads - almost every other system on the site depends on them, so this one's availability multiplies into everybody else's.
- Counts may be approximate and up to 60 seconds stale, stated as a requirement.
- A block must take effect on the next read, not on the next TTL.
Explicitly out of scope
The feed, notifications, recommendations and search. They are drawn as consumers because the shape of this system is decided by who reads it.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, an 8-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 8walkthrough steps
- 5tables22 columns
5 pages behind this one
- Capacity estimation
- Storage estimation
- Availability
- How it works
- Deployment plan
More boards
Timelines, follows, fan-out - the read-heavy classics.