Bird
Raised Fist0

Design LinkedIn - Professional Graph, Feed, Job Recommendations

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Gateway

Receives user request for feed and job recommendations

Validates user token and forwards request to Feed Processor

Protocol:HTTPS
BeforeUser is authenticated and sends request to API Gateway
AfterAPI Gateway forwards validated request to Feed Processor
Feed Processor

Publishes feed request event to Kafka topic

Encapsulates user ID and request parameters in event

Protocol:Kafka Produce
BeforeFeed Processor has received validated request from API Gateway
AfterFeed request event durably stored in Kafka topic
Kafka

Queues feed request event for consumption

Ensures ordered delivery of events to Graph Processor

Protocol:Kafka Consume
BeforeFeed request event is stored in Kafka topic
AfterGraph Processor receives feed request event from Kafka
Graph Processor

Queries Cassandra DB for user's professional graph data

Fetches connections and relevant metadata for recommendations

Protocol:Cassandra Query
BeforeGraph Processor has feed request event with user ID
AfterGraph Processor obtains user graph data from Cassandra
Cassandra DB

Returns user graph data to Graph Processor

Provides connections and metadata for recommendation generation

Protocol:Query Result
BeforeGraph Processor has queried Cassandra DB
AfterGraph Processor receives user graph data from Cassandra DB
Recommendation Service

Generates personalized recommendations using graph data

Checks Cache Layer for cached recommendations; updates cache if needed

Protocol:Redis GET / Redis SET
BeforeRecommendation Service has user graph data and feed request
AfterRecommendations cached and ready to be returned to API Gateway
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ HTTPS Request
        ▼
┌───────────────┐
│ Feed Processor│
└───────┬───────┘
        │ Kafka Produce
        ▼
┌───────────────┐
│    Kafka      │
└───────┬───────┘
        │ Kafka Consume
        ▼
┌───────────────┐
│Graph Processor│
└───────┬───────┘
        │ Cassandra Query
        ▼
┌───────────────┐
│ Cassandra DB  │
└───────┬───────┘
        │ Query Result
        ▼
┌───────────────────────────┐
│Recommendation Service      │
└───────┬───────────────┬───┘
        │ Redis GET     │ Redis SET
        ▼              ▼
┌───────────────┐  ┌───────────────┐
│Cache Layer    │  │Cache Layer    │
│(Redis/Memcached)│ │(Redis/Memcached)│
└───────────────┘  └───────────────┘
Design Rationale

This architecture shows a vertical flow from API Gateway to Recommendation Service, highlighting asynchronous decoupling via Kafka between Feed Processor and Graph Processor. The Graph Processor queries Cassandra DB for professional graph data, which is essential for personalized recommendations. The Recommendation Service leverages a Cache Layer to reduce latency and database load by caching results. This design balances real-time responsiveness with scalability by using Kafka for event-driven processing and Cassandra for high write throughput storage. The Cache Layer optimizes repeated queries, ensuring efficient feed and job recommendation delivery.

Primary Focus

✓

Practice

(1/5)
1. A web service requires encrypted communication with client browsers but must minimize CPU overhead on the server. Which component primarily handles the encryption and decryption workload during connection setup?
easy
A. The TLS handshake process managed by the server's SSL/TLS library
B. The client browser encrypting data before sending HTTP requests
C. The web application server performing manual encryption of HTTP payloads
D. The DNS server resolving domain names to IP addresses

Solution

  1. Step 1: Identify TLS handshake role

    The TLS handshake is responsible for negotiating encryption parameters and performing cryptographic operations to secure the connection.

  2. Step 2: Eliminate other options

    The web application server performing manual encryption of HTTP payloads is incorrect because manual encryption by the app server is inefficient and not standard. The client browser encrypting data before sending HTTP requests is incorrect because the client does not perform the handshake encryption workload; it participates but the server's TLS library handles the cryptographic operations. The DNS server resolving domain names to IP addresses is unrelated to encryption.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    TLS handshake handles encryption setup on server side [check]
Hint: TLS handshake manages encryption setup on server side [check]
Common Mistakes:
2. For propagating trace context across asynchronous messaging systems, which approach best preserves trace continuity without coupling services tightly?
medium
A. Embed trace context in message metadata headers supported by the messaging system
B. Use HTTP headers to propagate trace context in message payloads directly
C. Store trace context in a centralized database and have consumers query it on message receipt
D. Generate new trace IDs at each service and correlate offline during analysis

Solution

  1. Step 1: Understand asynchronous trace context propagation

    Embedding trace context in message metadata headers leverages messaging system features to propagate context without modifying payload or tight coupling.

  2. Step 2: Evaluate other options

    HTTP headers don't exist in messaging protocols. Centralized DB lookup adds latency and coupling. Generating new trace IDs breaks trace continuity and requires complex offline correlation.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Message metadata headers preserve trace context asynchronously [check]
Hint: Use message metadata headers, not payload or DB lookup [OK]
Common Mistakes:
3. If the API Gateway component is removed from a microservices architecture that relies on it for authentication and rate limiting, what is the most likely failure mode?
medium
A. Backend services will automatically reject unauthorized requests, so no failure occurs
B. Clients will be able to send unlimited requests directly to backend services, causing overload and security breaches
C. Reverse Proxy will cache authentication tokens, leading to stale authorization decisions
D. Load Balancer will take over authentication, causing increased latency but no security issues

Solution

  1. Step 1: Understand API Gateway role

    API Gateway centralizes authentication and rate limiting; without it, these controls are lost.

  2. Step 2: Trace failure consequences

    Load Balancer does not perform authentication but may attempt to handle some traffic control, increasing latency; backend services may be exposed to unauthorized requests.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Removing API Gateway removes centralized auth, Load Balancer can't fully compensate [check]
Hint: No API Gateway -> Load Balancer tries but can't secure backend [check]
Common Mistakes:
4. Without a centralized metrics aggregation system, what exactly breaks in alerting for service health in a microservices architecture?
medium
A. Alerting systems receive no aggregated latency or error rate data, causing delayed or missing alerts
B. Logs become unavailable, so debugging is impossible
C. Distributed tracing stops collecting spans, so request paths are lost
D. Services stop emitting any telemetry data, so monitoring dashboards freeze

Solution

  1. Step 1: Understand the role of metrics aggregation

    Metrics aggregation collects and summarizes latency and error rates needed for alerting.

  2. Step 2: Eliminate other options

    Logs and tracing are separate systems; services still emit telemetry but without aggregation alerting fails.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Missing metrics aggregation -> alerts lack data and fail [check]
Hint: No metrics aggregation -> no alert triggers [check]
Common Mistakes:
5. For a distributed API gateway enforcing rate limits per user, which design is best to handle burst traffic while maintaining consistency?
medium
A. Use local token buckets per gateway with periodic token sync and eventual consistency
B. Use a centralized Redis token bucket shared by all gateways with strong consistency
C. Use a fixed window counter stored in a distributed cache updated synchronously
D. Use a leaky bucket implemented in each gateway without synchronization

Solution

  1. Step 1: Evaluate centralized Redis token bucket

    Strong consistency causes high latency and bottlenecks under burst traffic.

  2. Step 2: Evaluate local token buckets with periodic sync

    Allows burst handling locally with eventual consistency, reducing latency and bottlenecks.

  3. Step 3: Eliminate fixed window and leaky bucket options

    Fixed window counters cause burst spikes; leaky bucket disallows bursts and lacks sync.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Local token buckets + eventual sync balance burst and consistency [check]
Hint: Local buckets + sync handle bursts and scale better [OK]
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