When a follow graph does not need a graph database

Model follow and follower edges for high-volume reads, sharding, reverse lookups, and repair using the lessons of FlockDB.

Social Graph Follows And FlockDB

Follow/follower storage looks like a graph problem, but not every graph-shaped problem needs a general graph database.

For Twitter-style follows, the hot operations are shallow adjacency-list reads:

who do I follow? who follows me? does A follow B? page through millions of followers, count followers/following.

Deep traversal is not the main requirement.

Day-Zero Relational Model

Use a generic table name like relations rather than follows if the product is likely to add:

close friends, blocks, mutes, favorites, groups, follow requests.

Generic does not mean vague. It means the table represents a product abstraction broader than one current button.

Why Sharding Breaks The Naive Query

If data is sharded by from user id , this is local:

But this can scatter across every shard:

The destination user could appear in rows whose sources live on many shards.

FlockDB Trick: Store Reverse Edges

For one follow action:

Now both reads are source-local: