Wednesday, May 27, 2026 · 9:41 AM
ok can you explain social graphs are relationship databases with sharp edges like i actually need to build it
a social graph stores relationships between entities, and the hard part is querying neighborhoods without melting on high-degree nodes
mental picture: it is a party map: who knows whom sounds simple until one person knows half the city
good, now do the real thing
not the fake diagram version
edges represent follows, friendships, blocks, memberships, likes, or permissions
directed edges fit follow models, undirected edges fit mutual friendship models
so the first move is making the invisible numbers visible
exactly
adjacency lists answer who does this user follow and who follows this user
what changes when this gets real traffic?
friend recommendations need traversals like friends-of-friends, shared interests, or graph ranking
celebrity nodes, privacy settings, blocks, and deleted accounts make naive traversal dangerous
wait, i thought the better answer was just adding the serious-sounding tool
that is the trap
the graph is not just data structure homework. product rules decide which edges are visible and usable
ok so what bill shows up later?
relational tables can work for simple edges
graph stores help deep traversal
precomputed recommendations are faster but can go stale or creepy
where do people usually mess this up?
running multi-hop graph queries live for every page load instead of caching or precomputing expensive neighborhoods
if i were designing this tomorrow, what should i write down first?
the read path
the write path
the thing that is allowed to be stale
the thing that absolutely is not
that is annoyingly practical
yeah. most system design is boring on purpose
model edge direction and privacy first, then choose live lookup, cache, or offline compute per feature
got it
less architecture cosplay, more pressure map
perfect
draw the pressure, then choose the machinery
Read Wed, May 27 · 9:58 AM