Bird
Raised Fist0

Design LinkedIn - Professional Graph, Feed, Job Recommendations

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design LinkedIn - Professional Graph, Feed, Job Recommendations
Design a scalable professional social network with graph, feed, and job recommendation features at LinkedIn scale
hardSocial Media and Feed SystemsFreq: high
Prerequisites:Collaborative FilteringEmbeddings
⚙️
Functional Requirements
  • Maintain a professional graph representing connections, follows, and endorsements between 800M+ users
  • Generate personalized feed with posts, articles, and updates from connections and followed entities
  • Provide job recommendations tailored to user profiles, activity, and network signals
  • Support real-time updates for feed and notifications with low latency
  • Allow users to search and filter jobs and professional content
  • Enable endorsements and skill validations within the professional graph
📊
Non-Functional Requirements
  • Support 2 billion daily active users (DAU) globally
  • Ensure 99.99% system availability with multi-region failover
  • Achieve 100ms P99 latency for feed retrieval and job recommendation queries
  • Handle peak write throughput of approximately 925K writes/sec (posts, connections, endorsements)
  • Scale storage to support 30 days of feed and graph data retention with replication
❓
Clarifying Questions to Ask
  • What is the expected average number of connections per user in the professional graph?
  • Are feed updates pushed in real-time or pulled on demand?
  • What is the retention period for feed and graph data?
  • What personalization signals are prioritized for job recommendations?
  • Is offline batch processing allowed for recommendation model training?
  • What are the SLAs for job search and feed update freshness?
Out of Scope
✗ Design of LinkedIn messaging or chat system
✗ Detailed UI/UX design for mobile or web clients
✗ Payment or subscription management systems
✗ Third-party integrations like external ATS or CRM systems
📌
Assumptions
  • 2 billion DAU globally
  • Average 40 feed-related write events per user per day (posts, likes, comments, endorsements)
  • Average message size 100 bytes per event
  • Average 50 read requests per user per day for feed and job recommendations
⚡
QPS Calculation
write qps2B × 40 / 86400 ≈ 925,926 writes/sec
peak write qpsAssuming 3× peak factor → 2.78M writes/sec
read qps2B × 50 / 86400 ≈ 1,157,407 reads/sec
💾
Storage Estimate
daily storage925,926 writes/sec × 100 bytes × 86400 sec ≈ 8 TB/day
retention days30
total storage8 TB/day × 30 days = 240 TB
with replication240 TB × 3 replicas = 720 TB total storage
🖥️
Server Estimate
write serversAssuming 10K writes/sec per Kafka partition, need ~278 Kafka partitions and 100 write servers
read serversAssuming 5K reads/sec per Cassandra node, need ~232 Cassandra nodes for read queries
🏗️
Architecture Diagram
Architecture Diagram
          +-------------+
          |   Clients   |
          +------+------+
                 |
          +------+-------+
          |  API Gateway |
          +------+-------+
                 |
   +-------------+--------------+
   |                            |
   v                            v
Feed Write Service          Graph Write Service
   |                            |
   +-------------+--------------+
                 |
          +------+-------+
          |   Kafka      |
          +------+-------+
                 |
   +-------------+--------------+
   |                            |
Feed Processor             Graph Processor
   |                            |
   +-------------+--------------+
                 |
          +------+-------+
          | Cassandra DB |
          +------+-------+
                 |
          +------+-------+
          | Recommendation|
          |    Service   |
          +------+-------+
                 |
          +------+-------+
          |  Cache Layer  |
          | (Redis/Memcached)|
          +--------------+
🧩
Components
API Gateway
Entry point for all client requests, routing to appropriate backend services
Why thisEnvoy proxy supports high throughput, TLS termination, and dynamic routing with low latency
Why notNginx lacks native service discovery and dynamic routing needed at LinkedIn scale
Kafka
Durable, partitioned event streaming platform for decoupling writes and asynchronous processing
Why thisKafka supports 10M+ writes/sec with strong ordering guarantees and retention policies
Why notRabbitMQ does not scale linearly beyond 100K messages/sec and lacks partitioning flexibility
Cassandra DB
Distributed wide-column store for storing professional graph and feed data with high write throughput
Why thisCassandra offers linear write scalability, tunable consistency, and multi-datacenter replication
Why notPostgreSQL requires complex manual sharding at 2.7M writes/sec; B-tree writes don't scale linearly
Feed Processor
Consumes Kafka feed events, enriches and writes to Cassandra for feed storage
Why thisApache Flink supports stateful stream processing with exactly-once semantics at scale
Why notSpark Streaming has higher latency and is less suited for real-time feed updates
Graph Processor
Processes graph mutations from Kafka and updates Cassandra professional graph tables
Why thisCustom microservice with Cassandra driver optimized for graph updates and consistency
Why notNeo4j cannot handle 2B DAU scale and high write throughput required
Recommendation Service
Generates personalized job and feed recommendations using embeddings and collaborative filtering
Why thisTensorFlow Serving enables scalable model inference with low latency and GPU acceleration
Why notCustom batch jobs cannot meet 100ms P99 latency for online recommendations
Cache Layer (Redis/Memcached)
Caches hot feed and recommendation results to reduce DB load and improve latency
Why thisRedis supports TTL expiration, pub/sub for cache invalidation, and sub-millisecond lookups
Why notMemcached lacks persistence and advanced eviction policies needed for complex cache invalidation
🔄
Data Flow
1
Clients → API Gateway
User posts, connections, endorsements, and feed requests sent
API Gateway routes requests to write or read services
2
API Gateway → Kafka
Write events (posts, graph mutations) published to Kafka topics
Decouples ingestion from processing for scalability

Practice

(1/5)
1. A database needs to support range queries on a large numeric column with frequent inserts and updates. Which indexing method best supports efficient range scans while maintaining balanced tree structure?
easy
A. Composite index on multiple columns, to speed up multi-column equality queries
B. Hash index, because it provides constant-time lookups for any key
C. B-Tree index, because it maintains sorted order and supports efficient range queries
D. Bitmap index, because it compresses well for high-cardinality numeric data

Solution

  1. Step 1: Identify index type for range queries

    B-Tree indexes maintain sorted order of keys, enabling efficient range scans by traversing leaf nodes sequentially.

  2. Step 2: Eliminate other options

    Hash indexes do not preserve order, so range queries require scanning all buckets. Composite indexes optimize multi-column equality but don't inherently improve single-column range scans. Bitmap indexes are efficient for low-cardinality columns, not large numeric ranges.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    B-Tree supports ordered traversal for range queries [check]
Hint: B-Tree keeps keys sorted for range queries [check]
Common Mistakes:
2. In the DNS query flow, at step 3 the GeoDNS server receives a DNS request from a user in Europe. What does the GeoDNS server do at this step?
easy
A. Returns the IP address of the closest data center based on the user's IP location
B. Forwards the DNS request to the authoritative DNS server without modification
C. Caches the DNS response from the previous query regardless of location
D. Performs a health check on all data centers before responding

Solution

  1. Step 1: Understand GeoDNS behavior at step 3

    GeoDNS inspects the user's IP to determine geographic location and returns the IP of the nearest data center accordingly.

  2. Step 2: Rule out other options

    Forwarding without modification (B) ignores GeoDNS's purpose. Caching regardless of location (C) breaks geographic routing. Health checks (D) are done asynchronously, not per query.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    GeoDNS returns location-based IP at query time [check]
Hint: GeoDNS returns nearest IP based on client IP at query [check]
Common Mistakes:
3. In a consistent hashing system with virtual nodes, at Step 4 the request router receives a key and must find the responsible physical node. What happens at this step?
easy
A. The router hashes the key, finds the closest virtual node clockwise, then maps to its physical node
B. The router hashes the key and assigns it to a random physical node to balance load
C. The router queries a centralized metadata service for the node responsible for the key
D. The router hashes the key and assigns it to the first physical node in the list

Solution

  1. Step 1: Trace request router behavior at Step 4

    The router uses the key's hash to find the closest virtual node clockwise on the ring.

  2. Step 2: Map virtual node to physical node

    Each virtual node maps to a physical node; the router routes the request accordingly.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Consistent hashing uses clockwise virtual node lookup to find physical node [check]
Hint: Hash key -> closest clockwise virtual node -> physical node [check]
Common Mistakes:
4. You must choose between a centralized logging system and a distributed tracing system to debug a latency spike affecting only a subset of microservices. Which is the better choice and why?
medium
A. Distributed tracing, because it shows end-to-end request paths and pinpoint latency bottlenecks
B. Centralized logging, because it aggregates metrics and alerts on latency spikes
C. Centralized logging, because it stores all events and can be searched easily
D. Distributed tracing, because it collects numerical metrics for alerting

Solution

  1. Step 1: Identify the debugging need for latency spike localization

    Tracing provides end-to-end request paths, revealing which microservices cause latency.

  2. Step 2: Eliminate logging options

    Logging stores events but doesn't easily correlate distributed latency; it's not optimized for path visualization or bottleneck pinpointing.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Tracing visualizes request paths to find latency hotspots [check]
Hint: Tracing maps request paths; logs record events [check]
Common Mistakes:
5. If the API Gateway's rate limiting cache fails and is not replaced, what is the immediate failure mode observed by users?
medium
A. Users receive explicit rate limit errors even when under limit
B. Requests bypass rate limiting, causing backend overload and degraded service
C. The system automatically switches to database-level rate limiting with no impact
D. All requests are silently dropped without response

Solution

  1. Step 1: Understand cache failure impact

    Without the cache, the API Gateway cannot track usage accurately, often defaulting to conservative rate limit errors to protect backend.

  2. Step 2: Evaluate other options

    Silent drops cause user confusion; bypassing limits risks overload; automatic fallback to DB rate limiting is rare and slow.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Cache failure -> conservative rate limit errors -> user impact [check]
Hint: Cache failure triggers conservative rate limit errors [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard