Bird
Raised Fist0

HTTP vs HTTPS - TLS Handshake, Certificate Chain, and the Cost

HLDmediumInterview freq: common
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Client (Browser/Device)

Initiates HTTPS request

Client sends ClientHello to start TLS handshake

Protocol:TLS
BeforeClient has plaintext HTTP request ready to send
AfterClientHello message sent, waiting for ServerHello
TLS Term Load Balancer

Receives ClientHello and forwards to termination server

Load balancer routes TLS handshake initiation

Protocol:TLS
BeforeLoad balancer idle, waiting for new TLS connection
AfterClientHello forwarded to TLS Term Server
TLS Term Server (Envoy/NGINX)

Responds with ServerHello and presents certificate chain

Server sends certificate chain to client

Protocol:TLS
BeforeTLS Term Server ready to handle handshake
AfterCertificate chain sent to client, awaiting validation
Certificate Validation Service

Validates certificate chain and revocation status

Checks certificate signatures and CRL/OCSP status

Protocol:Internal API
BeforeCertificate chain received, validation not started
AfterCertificate chain validated as trusted or rejected
TLS Term Server (Envoy/NGINX)

Completes TLS handshake if certificate valid

Establishes encrypted session and decrypts client data

Protocol:TLS
BeforeCertificate validation result received
AfterTLS session established, HTTP request decrypted
Application Server

Processes decrypted HTTP request

Handles business logic and generates response

Protocol:HTTP
BeforeDecrypted HTTP request received from TLS server
AfterResponse generated and sent back through TLS server
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│       Client                  │
│   (Browser/Device)            │
└───────────────┬───────────────┘
                │ HTTPS Request (TLS)
                ▼
┌───────────────────────────────┐
│ TLS Term Load Balancer        │
└───────────────┬───────────────┘
                │ TLS Handshake Init
                ▼
┌───────────────────────────────────────────┐
│ TLS Term Server (Envoy/NGINX)              │
│ - Handles TLS handshake                    │
│ - Presents server certificate              │
└───────────────┬───────────────────────────┘
                │ Certificate Chain Validation Request
                ▼
┌───────────────────────────────┐
│ Certificate Validation Service │
│ - Validates certificate chain  │
│ - Checks revocation status     │
└───────────────┬───────────────┘
                │ Validation Result
                ▼
┌───────────────────────────────┐
│ Application Server             │
│ - Processes decrypted request │
└───────────────────────────────┘
Design Rationale

This architecture illustrates the HTTPS request flow with TLS handshake and certificate validation. The Client initiates a TLS handshake by sending a ClientHello to the TLS Term Load Balancer, which routes it to the TLS Term Server (Envoy/NGINX). The server responds with a ServerHello and presents its certificate chain. The Certificate Validation Service verifies the chain's authenticity and revocation status, ensuring trust. Upon successful validation, the TLS session is established, and encrypted traffic is decrypted before forwarding the HTTP request to the Application Server. This layered approach adds latency and computational cost compared to HTTP but ensures confidentiality and integrity of data in transit.

Primary Focus

✓

Practice

(1/5)
1. A system requires 99.99% availability for a critical service that must tolerate a single data center failure without downtime. Which component is most appropriate to achieve this?
easy
A. Deploy active-active multi-region clusters with automatic failover
B. Rely on local in-memory caches to serve requests during outages
C. Use a single-region relational database with synchronous replication
D. Use a single data center with redundant power and network equipment

Solution

  1. Step 1: Understand availability target and failure domain

    99.99% availability requires tolerating entire data center failure without downtime, which single-region setups cannot guarantee.

  2. Step 2: Evaluate options for multi-region failover

    Active-active multi-region clusters with automatic failover provide seamless continuity, unlike local caches or single-region redundancy.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Multi-region active-active clusters -> tolerate data center failure [check]
Hint: Multi-region active-active -> survive data center failure [check]
Common Mistakes:
2. In the request flow, at Step 4 the Cache Node receives a key lookup request. What happens if the key is not found in the local cache at this step?
easy
A. The Cache Node immediately returns a cache miss to the client
B. The Cache Node forwards the request to the next node in the consistent hash ring
C. The Cache Node broadcasts the request to all cache nodes to find the key
D. The Cache Node fetches the value from the backing data store and updates its cache

Solution

  1. Step 1: Trace cache miss handling at Step 4

    On a miss, the node does not return immediately; it attempts to find the key elsewhere.

  2. Step 2: Broadcast vs forwarding

    Forwarding to next node breaks consistent hashing guarantees; fetching from backing store happens after confirming absence in cache cluster.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Cache node broadcasts to find key before fallback [check]
Hint: Cache miss triggers broadcast to find key in cluster [OK]
Common Mistakes:
3. A search ranking system must store and serve feature vectors for millions of users with low latency. Which component is best suited to provide fast, consistent feature retrieval at scale?
easy
A. A relational database with complex joins to compute features on demand
B. A distributed in-memory feature store with precomputed feature vectors
C. A batch processing system that recomputes features daily and stores them in object storage
D. A key-value store without versioning or consistency guarantees

Solution

  1. Step 1: Identify feature retrieval requirements

    Low latency and consistency for millions of users require fast, precomputed feature access.

  2. Step 2: Evaluate component suitability

    A relational DB with joins (A) is too slow for real-time; batch recomputation (C) is stale; key-value store without consistency (D) risks stale or inconsistent features. Distributed in-memory feature store (B) provides fast, consistent retrieval.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    In-memory feature store -> low latency, consistent features [check]
Hint: Precompute features in-memory for fast, consistent retrieval [check]
Common Mistakes:
4. If the gRPC server's message queue is removed, what exactly breaks in the message delivery flow?
medium
A. Clients receive duplicate messages due to lack of deduplication
B. The server blocks sending until the client acknowledges, causing backpressure
C. Messages are lost if the client is slow or disconnected, with no retry mechanism
D. The server switches to synchronous unary calls, increasing latency

Solution

  1. Step 1: Role of message queue in gRPC server

    The queue buffers messages for slow or disconnected clients, enabling retries and flow control.

  2. Step 2: Effect of removing the queue

    Without the queue, messages sent to slow/disconnected clients are dropped immediately, causing message loss without retries.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    No queue -> message loss on slow/disconnected clients [check]
Hint: No queue -> messages lost if client slow or disconnected [check]
Common Mistakes:
5. At 10x scale, which component in the distributed API rate limiter is most likely to fail first and why?
hard
A. Centralized logging service, because it cannot handle the increased write volume
B. API gateway, because it cannot maintain connections for all clients simultaneously
C. Distributed Counter cluster, because sharding limits cause hot partitions for popular users
D. Edge caches, because their local memory limits prevent storing counters for all users

Solution

  1. Step 1: Analyze component scalability

    Edge caches store counters in memory per user; memory is limited and grows with user count.

  2. Step 2: Compare bottlenecks

    Logging (A) can be scaled with partitioning; Distributed Counter (C) sharding mitigates hot spots; API gateway (D) scales horizontally. Edge caches (B) hit memory limits first, causing eviction or failures.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Edge caches fail first due to fixed local memory limits [check]
Hint: Edge caches limited by memory, fail before scalable components [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