Graph Databases

The Model

 data as NODES connected by typed RELATIONSHIPS:

 (sarah:User)──[:FRIENDS_WITH]──>(ahmed:User)
      │
      └──[:LIKES]──>(trails:Page)

 nodes carry properties; relationships are FIRST-CLASS:
 - typed, directed
 - carry their own properties (since=2023, weight=0.8)
 - traversable in constant-per-hop cost

Why Relational Strains Here

 "friends of friends who like pages my friends like":

 SQL: self-joins repeated per depth level.
 each level = one join; depth-4 queries become planner nightmares.

 THE JOIN DEPTH WALL:
   friends            1 hop    fine
   friends-of-friends 2 hops   slow but possible
   depth 3-5          joins EXPLODE combinatorially
   
 graphs make each HOP a pointer-follow (index-free adjacency):
   depth costs linearly. depth 6 social queries are routine.

Querying: Declarative Traversal

 Cypher-style:

 MATCH (u:User {id:'912'})-[:FRIENDS_WITH*1..3]->(friend)
 WHERE friend.city = 'london'
 RETURN friend

 reads like the QUESTION. the engine plans the traversal,
 using relationship structures relational stores lack.

What Graph Stores Buy vs Cost

✓ Wins	✗ Costs
Deep traversal (social, fraud rings, recommendations)	Bulk analytical scans (better in warehouses)
Relationship-rich domains	Operational niche-ness; smaller ecosystem
Schema flexibility on both nodes/edges	Sharding graphs is genuinely HARD
Natural fit for path/routing problems	Usually NOT needed below ~10M-node scale

 sharding difficulty deserves emphasis:
 graphs have no natural partition key — any cut severs edges.
 production answers: partition by subgraph (communities),
 replicate boundary nodes, or accept cross-partition hops.

When Graph Actually Fits

 ✓ fraud detection: money-laundering RINGS = multi-hop patterns
 ✓ recommendation engines: collaborative paths ("people-like-you")
 ✓ knowledge graphs / identity resolution  
 ✓ network/IT dependency mapping, root-cause analysis
 ✓ routing/logistics over dense networks

 reconsider when:
 ✗ shallow lookups dominate → relational FKs suffice
 ✗ analytics/aggregation heavy → columnar warehouse
 ✗ team can't operate a niche store → Postgres + recursive CTEs
   handles moderate-depth cases honestly well

The Pragmatic Ladder

 before adopting a graph store, try IN ORDER:

 1. recursive CTEs in Postgres     depth ≤ 4, moderate data
 2. app-level BFS over indexed FKs controlled fan-outs
 3. dedicated graph store          deep/unbounded traversal demand
 
 most teams discover step 1 sufficed for years.
 adoption justified by MEASURED traversal needs, not resume.

Interview Framing

“Design friend suggestions” tests graph judgment: model as nodes+edges verbally, note where relational dies (multi-hop), then EITHER justify Neo4j for unbounded depth OR defend recursive-CTE Postgres for bounded depth + smaller ops burden. Naming the sharding problem unprompted marks genuine familiarity rather than buzzword recall.