Design a Graph Database Service (Neo4j)

To design a Graph Database Service for Meta's social graph, I would first clarify that we need sub-millisecond latency for 'friends of friends' queries across billions of users. For the data model, I'd represent Users as nodes with properties like ID and profile metadata, while interactions become directed edges with weights indicating interaction frequency. We would use a property graph model rather than RDF to support flexible querying via a language like Cypher or Gremlin. For storage, a distributed approach is essential. I'd shard the graph based on user communities to minimize cross-shard traversal during feed generation, ensuring that highly connected clusters stay co-located. To handle write-heavy ingestion from likes and comments, I'd implement an append-only log with periodic compaction to maintain read performance. Query optimization is critical here. Instead of naive traversal, I'd propose maintaining pre-computed short-path indices for common query depths, similar to how Facebook optimizes friend suggestions. For deep recommendations, we'd use iterative graph algorithms running on a separate compute layer to avoid blocking primary reads. Finally, regarding consistency, given Meta's global scale, I'd opt for eventual consistency for non-critical social metrics but strong consistency for core relationship states like blocking or friendship acceptance to ensure user trust.