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
🏗️
Client-Server Architecture and Why It Is the Foundation of Every System
Understanding the client-server model as the backbone of scalable distributed systems
mediumCore Distributed Systems ConceptsFreq: high
Prerequisites:System Design FundamentalsCAP Theorem
⚙️
Functional Requirements
  • Clients send requests to servers for data or computation.
  • Servers process client requests and return responses.
  • Support concurrent connections from millions of clients.
  • Maintain session or state information as needed.
  • Enable authentication and authorization of clients.
  • Allow horizontal scaling of servers to handle load.
📊
Non-Functional Requirements
  • Support up to 2 billion daily active users (DAU).
  • Achieve 99.99% availability SLA for client requests.
  • Ensure 100ms P99 latency for request-response cycle.
  • Handle peak write QPS of approximately 925,000 messages/sec.
  • Support data durability with replication factor of 3.
❓
Clarifying Questions to Ask
  • What is the expected request and response payload size?
  • Are clients stateful or stateless in their interactions?
  • What consistency guarantees are required for data?
  • Is the system read-heavy, write-heavy, or balanced?
  • What are the security requirements for client-server communication?
  • Are there any geographic distribution or latency constraints?
Out of Scope
✗ Designing specific application business logic beyond request handling.
✗ Client-side UI/UX design and rendering.
✗ Detailed network protocol design below TCP/IP.
✗ Advanced caching strategies beyond basic client-server interaction.
📌
Assumptions
  • 2 billion DAU
  • Each user sends 40 messages per day
  • Average message/request size is 100 bytes
  • Replication factor of 3 for durability
⚡
QPS Calculation
write qps2,000,000,000 × 40 / 86,400 ≈ 925,926 msg/sec
peak write qpsAssuming 2× peak factor → 1,851,852 msg/sec
read qpsAssuming 3 reads per write → 2,777,778 reads/sec
💾
Storage Estimate
daily storage925,926 msg/sec × 100 bytes × 86,400 sec ≈ 8 TB/day
retention days30
total storage8 TB/day × 30 days × 3 (replication) = 720 TB
🖥️
Server Estimate
api serversAssuming 10,000 req/sec per server → 2,777,778 / 10,000 ≈ 278 servers
database nodesAssuming 1000 writes/sec per Cassandra node → 1,851,852 / 1000 ≈ 1852 nodes
🏗️
Architecture Diagram
Architecture Diagram
          +------------+
          |   Clients  |
          +-----+------+
                |
                v
         +------+-------+
         | Load Balancer|
         +------+-------+
                |
                v
         +------+-------+
         |  API Servers |
         +------+-------+
                |
                v
         +------+-------+
         |  Auth Server |
         +------+-------+
                |
                v
         +------+-------+
         | Cassandra DB |
         +------+-------+
                |
                v
         +------+-------+
         | Kafka Broker |
         +--------------+
🧩
Components
Load Balancer
Distributes incoming client requests evenly across API servers to prevent overload.
Why thisAWS ELB or NGINX supports millions of concurrent connections with health checks and SSL termination.
Why notDNS round-robin lacks health checks and fine-grained load distribution, causing uneven load and downtime.
API Servers
Handle client requests, perform business logic, and communicate with backend services.
Why thisStateless RESTful servers (e.g., Node.js or Go) allow horizontal scaling and easy deployment.
Why notMonolithic servers limit scalability and increase deployment risk.
Auth Server
Manages client authentication and authorization securely.
Why thisOAuth 2.0 compliant servers (e.g., Keycloak) provide standardized token management and scalability.
Why notCustom auth implementations risk security flaws and poor scalability.
Cassandra DB
Stores client data with high write throughput and horizontal scalability.
Why thisCassandra supports linear write scaling, tunable consistency, and multi-datacenter replication.
Why notPostgreSQL requires complex manual sharding at 925K writes/sec; B-tree writes don't scale linearly.
Kafka Broker
Asynchronous message queue for decoupling write-heavy ingestion and downstream processing.
Why thisKafka handles millions of messages per second with durable, partitioned logs and consumer groups.
Why notRabbitMQ lacks the throughput and partitioning needed for 1.8M msg/sec peak load.
🔄
Data Flow
1
Client → Load Balancer
Client sends request (e.g., message or data fetch).
Load balancer evenly distributes requests to API servers.
2
Load Balancer → API Server
Forward client request to an available API server.
API servers are stateless and horizontally scalable.
3
API Server → Auth Server
Validate client authentication token.
Ensures secure access before processing request.
4
API Server → Cassandra DB
Read/write client data as per request.
Cassandra handles high write throughput with replication.
5
API Server → Kafka Broker
Publish event/message asynchronously for downstream processing.
Decouples ingestion from processing to improve throughput.
6
API Server → Client
Send response back to client with requested data or status.
Ensures 100ms P99 latency target.

Practice

(1/5)
1. In the request flow of a real-time ML inference system, at Step 4 the Model Router receives a prediction request. What happens if the system is currently in shadow mode with a new model deployed?
easy
A. The Model Router sends the request to both the production and shadow models but returns only the production model's prediction.
B. The Model Router forwards the request only to the new shadow model and returns its prediction.
C. The Model Router queues the request until the shadow model finishes training before forwarding.
D. The Model Router rejects the request to avoid inconsistent predictions during shadow testing.

Solution

  1. Step 1: Understand shadow mode request routing

    Shadow mode runs new models in parallel without affecting live traffic. So, requests are sent to both models.

  2. Step 2: Identify response behavior

    Only the production model's prediction is returned to the client; shadow model predictions are logged for evaluation.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Shadow mode duplicates requests but returns production output [check]
Hint: Shadow mode duplicates requests; only production output returned [OK]
Common Mistakes:
2. In the order processing pipeline, at step 5 the Inventory Service checks stock availability. What is the state of the order if the Inventory Service finds insufficient stock at this step?
easy
A. Order is immediately cancelled and removed from the system
B. Order is marked as 'Confirmed' but flagged for manual review
C. Order status is updated to 'Pending Stock' and placed in a retry queue
D. Order processing continues but with a backorder flag set

Solution

  1. Step 1: Trace Inventory Service check at Step 5

    Inventory Service detects insufficient stock and cannot confirm order immediately.

  2. Step 2: Understand retry mechanism

    System updates order to 'Pending Stock' and enqueues it for retry once stock replenishes, avoiding immediate cancellation or false confirmation.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Insufficient stock -> 'Pending Stock' + retry queue [check]
Hint: Insufficient stock triggers retry queue, not immediate cancel [check]
Common Mistakes:
3. A REST API needs to support clients fetching large lists of user records without overwhelming the server or client memory. Which design principle best addresses this requirement?
easy
A. Implement pagination with query parameters like page and limit
B. Use HTTP POST to send the entire user list in the request body
C. Return all user records in a single response with HTTP 200 status
D. Use HTTP PUT to update the user list incrementally

Solution

  1. Step 1: Identify the need to limit response size

    Fetching large lists risks high memory usage and slow responses; pagination limits data per request.

  2. Step 2: Recognize pagination as the standard REST approach

    Using query parameters like page and limit allows clients to request manageable chunks.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Pagination with query params controls response size [check]
Hint: Paginate large lists with query params [check]
Common Mistakes:
4. For a high-traffic e-commerce site needing to invalidate product pages immediately after price updates, which cache invalidation strategy is best and why?
medium
A. Use surrogate keys to invalidate all related product pages atomically
B. Use client-side cache control headers to force revalidation
C. Use short TTL to ensure freshness but accept higher cache misses
D. Use long TTL with manual purge to minimize cache misses

Solution

  1. Step 1: Identify need for immediate, atomic invalidation

    Price updates require instant invalidation of all related pages to avoid stale data.

  2. Step 2: Evaluate strategies

    Long TTL with manual purge delays invalidation; short TTL causes high cache misses; client-side headers don't guarantee server cache invalidation; surrogate keys enable atomic invalidation of related content.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Surrogate keys enable atomic, immediate invalidation of related cache [check]
Hint: Surrogate keys invalidate related content atomically [check]
Common Mistakes:
5. For a globally distributed system requiring unique IDs with strict time ordering, which approach is best considering clock skew and network latency?
medium
A. Use a centralized timestamp authority to assign IDs to all machines.
B. Use Snowflake IDs with synchronized clocks and machine IDs to generate IDs locally.
C. Use UUID v1 with MAC address and timestamp for uniqueness and ordering.
D. Use random 64-bit IDs generated independently on each machine.

Solution

  1. Step 1: Evaluate centralized timestamp authority

    Centralized authority (A) creates a bottleneck and single point of failure, unsuitable for global scale.

  2. Step 2: Assess UUID v1 and random IDs

    UUID v1 (C) includes MAC and timestamp but has weak ordering guarantees and privacy concerns; random IDs (D) lack ordering.

  3. Step 3: Analyze Snowflake approach

    Snowflake (B) uses synchronized clocks and machine IDs to generate unique, time-ordered IDs locally, tolerating minor clock skew with sequence numbers.

  4. Final Answer:

    Option B -> Option B

  5. Quick Check:

    Snowflake balances ordering and decentralization despite clock skew [check]
Hint: Local generation with synced clocks beats centralized bottlenecks [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