Bird
Raised Fist0

Client-Server Architecture and Why It Is the Foundation of Every System

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Load Balancer

Receives client HTTP request

Load Balancer accepts incoming request and selects API Server

Protocol:HTTP/HTTPS
BeforeClient request is sent over the internet
AfterRequest is routed to one API Server instance
API Servers

Processes request and forwards credentials

API Server extracts credentials and calls Auth Server

Protocol:Internal REST
BeforeAPI Server has raw client request with credentials
AfterCredentials sent to Auth Server for validation
Auth Server

Validates credentials and returns token

Auth Server checks credentials and issues auth token

Protocol:Auth Token
BeforeAuth Server receives credentials from API Server
AfterAuth Server returns valid token to API Server
API Servers

Publishes request event to Kafka

API Server sends event message for async processing

Protocol:Kafka Msg
BeforeAPI Server has authenticated request ready for processing
AfterRequest event durably stored in Kafka Broker
Kafka Broker

Delivers message to Cassandra DB consumer

Kafka Broker forwards message to downstream consumer

Protocol:Kafka Msg
BeforeMessage is stored in Kafka topic partition
AfterMessage consumed and passed to Cassandra DB writer
Cassandra DB

Persists request data

Cassandra DB writes data to distributed storage

Protocol:CQL (Cassandra Query Language)
BeforeCassandra DB awaits new data to persist
AfterRequest data durably stored in Cassandra cluster
🏗️
Architecture Diagram
Architecture Diagram
          ┌───────────────┐
          │ Load Balancer │
          └───────┬───────┘
                  │ HTTP/HTTPS
                  ▼
          ┌───────────────┐
          │  API Servers  │
          └───────┬───────┘
                  │ Internal REST
                  ▼
          ┌───────────────┐
          │  Auth Server  │
          └───────┬───────┘
                  │ Auth Token
                  ▼
          ┌───────────────┐
          │ Kafka Broker  │
          └───────┬───────┘
                  │ Kafka Msg
                  ▼
          ┌───────────────┐
          │ Cassandra DB  │
          └───────────────┘
Design Rationale

This client-server architecture illustrates a typical request flow starting at the Load Balancer, which distributes incoming HTTP requests to API Servers. The API Servers handle business logic and delegate authentication to the Auth Server via internal REST calls. Upon successful authentication, the API Server publishes an event message to the Kafka Broker, enabling asynchronous processing and decoupling. Kafka ensures durable message storage and delivery to downstream consumers, here represented by Cassandra DB, which persists the request data in a distributed NoSQL store. This layered approach separates concerns, improves scalability, and ensures reliability by leveraging asynchronous messaging and distributed storage.

Primary Focus

✓

Practice

(1/5)
1. In a system where Step 4 is the Delivery Worker checking message delivery status, what happens if the Delivery Worker finds the recipient's presence TTL expired?
easy
A. The Delivery Worker queues the message for offline delivery and updates status to 'sent but not delivered'
B. The Delivery Worker immediately marks the message as delivered without retry
C. The Delivery Worker deletes the message assuming recipient is unreachable
D. The Delivery Worker retries sending indefinitely until TTL is refreshed

Solution

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

    If TTL expired, recipient is offline; message can't be delivered immediately.

  2. Step 2: Understand offline delivery handling

    Delivery Worker queues message for later delivery and marks status as 'sent but not delivered' to reflect state.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired TTL -> queue message, status 'sent but not delivered' [check]
Hint: Expired TTL means offline, queue message for later delivery [check]
Common Mistakes:
2. A system needs to estimate the number of unique users visiting a website daily, with minimal memory usage and acceptable error margin. Which component is best suited to handle this requirement?
easy
A. A Redis cache storing all user IDs explicitly
B. A relational database with unique user ID indexing
C. A HyperLogLog data structure for cardinality estimation
D. A Bloom filter to check if a user has visited before

Solution

  1. Step 1: Understand memory constraints and error tolerance

    Storing all user IDs explicitly (Redis or relational DB) is memory-heavy and not scalable for large user bases.

  2. Step 2: Identify HyperLogLog's role

    HyperLogLog provides approximate unique counts with fixed small memory and tunable error, ideal for large-scale cardinality estimation.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    HyperLogLog trades accuracy for memory efficiency [check]
Hint: Approximate unique counts with tiny memory -> HyperLogLog [check]
Common Mistakes:
3. If the Progress Worker crashes before persisting a user's video watch progress, what is the exact failure observed by the user when they resume the course?
medium
A. User sees progress reset to zero and must rewatch videos from the start
B. User's progress appears stuck at last persisted checkpoint, missing recent watch time
C. User receives an error message preventing course continuation until retry
D. User's progress is duplicated causing certificate issuance errors

Solution

  1. Step 1: Trace failure impact of Progress Worker crash

    Progress Worker crash before persistence means recent watch time is lost.

  2. Step 2: Evaluate user experience on resume

    System detects missing progress update and returns error preventing continuation (User receives an error message preventing course continuation until retry), rather than silently resetting or duplicating progress.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Crash causes error blocking course continuation until retry [check]
Hint: Crash blocks progress update, user sees error [OK]
Common Mistakes:
4. For a mobile app requiring low-latency, reliable connections over lossy networks, which HTTP version trade-off is best and why?
medium
A. Use HTTP/1.1 because it uses TCP which guarantees ordered delivery
B. Use HTTP/2 with TLS 1.2 for best compatibility and performance
C. Use HTTP/2 because multiplexing streams over TCP reduces latency on stable networks
D. Use HTTP/3 because QUIC over UDP reduces head-of-line blocking and improves loss recovery

Solution

  1. Step 1: Analyze network conditions and protocol features

    Mobile lossy networks benefit from QUIC's UDP-based transport which avoids TCP head-of-line blocking and has faster loss recovery.

  2. Step 2: Compare HTTP versions

    HTTP/1.1 TCP suffers head-of-line blocking; HTTP/2 multiplexing still uses TCP and inherits its limitations; HTTP/3 with QUIC improves latency and reliability on lossy links.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    HTTP/3 QUIC reduces head-of-line blocking on lossy networks [check]
Hint: HTTP/3 QUIC beats TCP head-of-line blocking on lossy links [check]
Common Mistakes:
5. Without the use of consistent hashing in a distributed cache, what failure scenario occurs when a node is removed?
medium
A. Only the keys assigned to the removed node are lost permanently
B. The system automatically replicates keys to other nodes without delay
C. Clients continue to query the removed node causing request failures
D. All keys must be remapped causing a cache-wide performance degradation and potential cache stampede

Solution

  1. Step 1: Understand modular hashing failure on node removal

    Modular hashing requires remapping all keys, causing performance degradation and cache misses.

  2. Step 2: Evaluate options

    The system automatically replicates keys to other nodes without delay incorrectly assumes automatic replication without delay; Clients continue to query the removed node causing request failures is invalid as clients rely on updated routing.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without consistent hashing, remapping causes cache stampede, no instant replication [check]
Hint: No consistent hashing -> full remap, cache stampede risk [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