Bird
Raised Fist0

Service Discovery - Client-Side vs Server-Side Patterns

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/8
Client Service (Client-Side Discovery)

Queries Cache Layer for service endpoint

Client sends Redis GET request to find service instance IP

Protocol:Redis GET
BeforeClient has no cached service endpoint
AfterClient receives cached service endpoint or cache miss
Cache Layer (Redis Cluster)

Checks for cached service endpoint

Returns cached IP if present, else cache miss

Protocol:Redis GET
BeforeCache contains recent service endpoints or is empty
AfterCache returns endpoint or indicates miss
Client Service (Client-Side Discovery)

On cache miss, queries Service Registry directly

Sends HTTP API request to Consul for service instances

Protocol:HTTP API
BeforeClient has no endpoint from cache
AfterClient receives fresh service instance list
Service Registry (Consul)

Responds with healthy service instances

Returns list of healthy instances based on health checks

Protocol:HTTP API
BeforeRegistry has up-to-date health info from Health Check Worker
AfterRegistry sends healthy instances to client
Health Check Worker

Periodically updates service health status

Sends health check results to Service Registry

Protocol:HTTP API
BeforeService health status may be stale
AfterRegistry has fresh health status for routing
Client Service (Client-Side Discovery)

Calls target service instance directly

Sends request to discovered service IP

Protocol:HTTP
BeforeClient has service instance IP
AfterRequest sent directly to service instance
Server-Side Proxy (Envoy)

Receives client request and performs discovery

Envoy queries Service Registry to route request

Protocol:HTTP API
BeforeEnvoy has no cached endpoint for target service
AfterEnvoy routes request to healthy service instance
Target Service Instance

Processes client request

Handles request and sends response

Protocol:HTTP
BeforeService instance is idle or processing other requests
AfterService instance processes and responds to request
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│ Client Service                │
│ (Client-Side Discovery)       │
└───────────────┬───────────────┘
                │ DNS Lookup /  
                │ Service Query 
                ▼              
┌───────────────────────────────┐
│ Cache Layer                  │
│ (Redis Cluster)              │
└───────────────┬───────────────┘
                │ Redis GET    
                ▼              
┌───────────────────────────────┐
│ Service Registry             │
│ (Consul)                    │
└───────────────┬───────────────┘
                │ HTTP API    
                ▼              
┌───────────────────────────────┐
│ Health Check Worker          │
│ (Updates Service Registry)  │
└───────────────────────────────┘
                               
┌───────────────────────────────┐
│ Server-Side Proxy            │
│ (Envoy)                     │
└───────────────┬───────────────┘
                │ Routes Req  
                ▼              
┌───────────────────────────────┐
│ Target Service Instance      │
│ (Discovered by Envoy)        │
└───────────────────────────────┘
Design Rationale

This architecture diagram contrasts client-side and server-side service discovery patterns. In client-side discovery, the Client Service queries a Cache Layer (Redis) first to find service endpoints, falling back to the Service Registry (Consul) if needed. The Health Check Worker ensures the registry has fresh health data. The client then calls the service instance directly. In server-side discovery, the Server-Side Proxy (Envoy) receives client requests and queries the Service Registry to route requests to healthy instances, abstracting discovery from clients. This design highlights trade-offs: client-side discovery reduces proxy complexity but requires clients to handle discovery logic, while server-side discovery centralizes routing but adds proxy overhead. The Cache Layer reduces load on the registry and improves latency for client-side discovery.

Primary Focus

✓

Practice

(1/5)
1. In the notification system's request flow, at Step 4 the Delivery Worker reads a notification from Kafka and checks the user's device presence cache. What happens if the presence TTL has expired for that user?
easy
A. The Delivery Worker immediately retries sending the notification to the last known device
B. The Delivery Worker skips push delivery and falls back to SMS or email channels
C. The Delivery Worker marks the notification as delivered without sending
D. The Delivery Worker queues the notification back into Kafka for later retry

Solution

  1. Step 1: Trace Delivery Worker decision at Step 4 -- Bob's presence TTL

    If the presence TTL expired, the system assumes the user is offline for push and falls back to alternative channels like SMS or email.

  2. Step 2: Eliminate other options

    Immediate retry (A) wastes resources if device is offline; marking as delivered (C) loses notification; re-queuing (D) causes infinite retry loops.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Expired presence TTL -> fallback to SMS/email [check]
Hint: Expired presence triggers fallback, not silent delivery [check]
Common Mistakes:
2. In the task scheduler's execution flow, at Step 4 the Worker Node polls the distributed priority queue for the next task. What happens if the task's scheduled time has not yet arrived?
easy
A. The Worker Node marks the task as failed due to premature execution
B. The Worker Node re-queues the task with the same priority and waits
C. The Worker Node skips the task and polls for the next available task
D. The Worker Node immediately executes the task ignoring the schedule

Solution

  1. Step 1: Understand Worker Node behavior at Step 4

    The Worker Node must respect the scheduled execution time; executing early (A) violates correctness; re-queuing (B) risks duplicate tasks; skipping (C) ignores the task indefinitely.

  2. Step 2: Identify failure handling

    Marking the task as failed (D) triggers retry or alert mechanisms, ensuring no premature execution and visibility into scheduling issues.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Premature tasks are failed to prevent early execution [check]
Hint: Fail early if task scheduled time not reached [check]
Common Mistakes:
3. During a global network outage caused by BGP misconfiguration, which recovery approach balances speed and safety best for restoring connectivity without causing routing loops?
medium
A. Gradually reintroduce routes with route flap damping to prevent instability
B. Immediately re-advertise all withdrawn routes globally to restore traffic
C. Use static routing entries temporarily to bypass BGP until full recovery
D. Rely on client-side retries and exponential backoff to handle transient failures

Solution

  1. Step 1: Understand recovery trade-offs

    Immediate re-advertisement (A) risks routing loops and instability; static routes (C) don't scale globally; client retries (D) don't fix routing issues.

  2. Step 2: Evaluate gradual reintroduction

    Route flap damping (B) prevents rapid route changes causing instability, balancing speed and safety during recovery.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Route flap damping prevents loops during gradual route restoration [check]
Hint: Gradual route reintroduction with damping avoids loops [check]
Common Mistakes:
4. For a system requiring cost optimization with infrequent data access but occasional retrieval within hours, which storage architecture is preferable?
medium
A. Implement warm storage with HDDs and cold storage with object storage, migrating data based on access patterns
B. Use only hot storage with SSDs for all data to ensure fastest access
C. Archive all data immediately to tape storage to minimize cost
D. Store all data in cold storage with no tiering to simplify design

Solution

  1. Step 1: Analyze access and cost requirements

    Data is infrequently accessed but needs retrieval within hours, so cold storage alone is too slow.

  2. Step 2: Evaluate tiering benefits

    Warm storage offers moderate cost and latency; cold storage reduces cost further. Tiering balances cost and retrieval time.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Warm + cold tiering balances cost and retrieval latency [check]
Hint: Warm + cold tiering balances cost and latency [check]
Common Mistakes:
5. If the sequence number state is lost due to a node crash in a Snowflake-like ID generator, what is the immediate failure observed in the system?
medium
A. The generator blocks until the sequence number is recovered from persistent storage
B. The generator resets the timestamp to an earlier value to avoid duplicates
C. The generator produces duplicate IDs for the same timestamp causing collisions downstream
D. The generator switches to UUID v4 fallback to avoid duplicates

Solution

  1. Step 1: Understand failure handling in sequence number loss

    Some implementations fallback to UUID v4 to avoid duplicates when sequence state is lost.

  2. Step 2: Evaluate other options

    Blocking causes latency; duplicate IDs cause collisions; resetting timestamp breaks ordering guarantees.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Fallback to UUID v4 avoids duplicates despite losing ordering [check]
Hint: Fallback to UUID v4 avoids duplicates after sequence loss [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