Bird
Raised Fist0
HLDsystem_design~12 mins

Social graph storage in HLD - Architecture Diagram

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
System Overview - Social graph storage

This system stores and manages social connections between users, such as friendships or followers. It must handle fast queries to find friends, mutual connections, and support updates like adding or removing connections efficiently.

Architecture Diagram
User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
+-------------------+       +----------------+
| Social Graph       |<----->| Cache (Redis)  |
| Service           |       +----------------+
| (Handles queries,  |
|  updates)          |
+-------------------+
          |
          v
+-------------------+
| Graph Database     |
| (e.g., Neo4j,      |
|  Cassandra with    |
|  graph model)      |
+-------------------+
Components
User
user
End user who sends requests to view or update social connections
Load Balancer
load_balancer
Distributes incoming user requests evenly to API Gateway instances
API Gateway
api_gateway
Entry point for client requests, handles authentication and routing
Social Graph Service
service
Processes social graph queries and updates, interacts with cache and database
Cache (Redis)
cache
Stores frequently accessed social graph data to reduce database load and improve response time
Graph Database
database
Stores the social graph data with relationships, supports complex graph queries
Request Flow - 10 Hops
User → Load Balancer
Load Balancer → API Gateway
API Gateway → Social Graph Service
Social Graph Service → Cache (Redis)
Cache (Redis) → Social Graph Service
Social Graph Service → Graph Database
Graph Database → Social Graph Service
Social Graph Service → Cache (Redis)
Social Graph Service → API Gateway
API Gateway → User
Failure Scenario
Component Fails:Graph Database
Impact:New updates to social connections fail; cache may serve stale read data
Mitigation:Use database replication for failover; serve reads from cache during outage; queue updates for retry
Architecture Quiz - 3 Questions
Test your understanding
Which component is responsible for distributing incoming user requests evenly?
ALoad Balancer
BAPI Gateway
CCache
DGraph Database
Design Principle
This architecture uses caching to reduce database load and improve response times for social graph queries. The load balancer and API gateway ensure scalable and secure request handling. The graph database stores complex relationships efficiently, while cache and replication improve availability and performance.

Practice

(1/5)
1. What is the primary purpose of social graph storage in system design?
easy
A. To handle user authentication and authorization
B. To store only user profile data without connections
C. To manage database backups efficiently
D. To store users as nodes and their relationships as edges

Solution

  1. Step 1: Understand social graph components

    Social graph storage models users as nodes and their relationships as edges.

  2. Step 2: Identify the main function

    The main function is to represent and query user connections, not just user data or security.

  3. Final Answer:

    To store users as nodes and their relationships as edges -> Option D

  4. Quick Check:

    Social graph = nodes + edges [OK]
Hint: Remember: social graph = users + connections [OK]
Common Mistakes:
  • Confusing social graph with user profile storage
  • Thinking it handles authentication
  • Assuming it manages backups
2. Which data structure is most suitable to represent a social graph for efficient traversal?
easy
A. Stack
B. Array
C. Adjacency list
D. Queue

Solution

  1. Step 1: Review data structures for graph representation

    Adjacency lists store each node with a list of connected nodes, ideal for sparse graphs like social networks.

  2. Step 2: Compare with other options

    Arrays don't efficiently represent connections; stacks and queues are traversal helpers, not storage.

  3. Final Answer:

    Adjacency list -> Option C

  4. Quick Check:

    Efficient graph storage = adjacency list [OK]
Hint: Use adjacency list for sparse graph storage [OK]
Common Mistakes:
  • Choosing arrays which waste space
  • Confusing traversal structures with storage
  • Ignoring graph sparsity
3. Given a social graph stored as an adjacency list: {'Alice': ['Bob', 'Carol'], 'Bob': ['Alice'], 'Carol': ['Alice']}, what is the output of querying Alice's friends?
medium
A. ['Bob']
B. ['Bob', 'Carol']
C. ['Alice']
D. []

Solution

  1. Step 1: Locate Alice in adjacency list

    Alice's entry shows connections to Bob and Carol.

  2. Step 2: Return Alice's friends list

    The list associated with Alice is ['Bob', 'Carol'].

  3. Final Answer:

    ['Bob', 'Carol'] -> Option B

  4. Quick Check:

    Alice's friends = ['Bob', 'Carol'] [OK]
Hint: Check adjacency list key for user connections [OK]
Common Mistakes:
  • Returning the user name instead of friends
  • Confusing direction of edges
  • Returning empty list by mistake
4. In a social graph system, a developer tries to add a friendship edge between two users but the system crashes. Which is the most likely cause?
medium
A. The users do not exist in the graph nodes
B. The graph uses an adjacency list
C. The system uses directed edges
D. The graph is stored in a relational database

Solution

  1. Step 1: Analyze the crash cause

    Adding an edge requires both users to exist as nodes; missing nodes cause errors.

  2. Step 2: Evaluate other options

    Adjacency list, directed edges, or relational storage do not inherently cause crashes when adding edges.

  3. Final Answer:

    The users do not exist in the graph nodes -> Option A

  4. Quick Check:

    Missing nodes cause edge addition failure [OK]
Hint: Ensure both users exist before adding edges [OK]
Common Mistakes:
  • Blaming data structure choice for crash
  • Ignoring node existence before edge creation
  • Assuming direction causes crash
5. You need to design a social graph storage system that supports millions of users and fast friend-of-friend queries. Which approach is best?
hard
A. Use a distributed graph database with adjacency lists and caching
B. Store all connections in a single relational table with indexes
C. Use flat files to store user connections sequentially
D. Keep all data in memory without persistence

Solution

  1. Step 1: Consider scalability and query needs

    Millions of users require distributed storage and efficient traversal for friend-of-friend queries.

  2. Step 2: Evaluate options for performance and scalability

    Distributed graph databases with adjacency lists and caching optimize query speed and handle scale; relational tables or flat files are less efficient; in-memory only lacks persistence.

  3. Final Answer:

    Use a distributed graph database with adjacency lists and caching -> Option A

  4. Quick Check:

    Scale + fast queries = distributed graph DB + caching [OK]
Hint: Combine distribution, adjacency lists, and caching for scale [OK]
Common Mistakes:
  • Choosing relational tables for large graph queries
  • Using flat files which are slow
  • Ignoring persistence by using memory only