Bird
Raised Fist0

Multi-CDN Strategy for Maximum Availability and Geo Coverage

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/5
Global DNS Load Balancer

Receives DNS query from user

User requests domain resolution; load balancer prepares to route

Protocol:DNS Query (UDP)
BeforeUser has initiated DNS query for service domain
AfterGlobal DNS Load Balancer received query and will forward to CDN Selection
CDN Selection Service

Queries Health Monitor for CDN health status

Determines which CDN is healthy and optimal for user location

Protocol:REST API Call
BeforeCDN Selection Service has no recent health info for CDNs
AfterCDN Selection Service has latest health data for CDN A and CDN B
Health Monitor Service

Responds with health status of CDNs

Reports CDN A is healthy, CDN B is degraded

Protocol:gRPC
BeforeHealth Monitor Service has latest health metrics from CDN endpoints
AfterHealth Monitor Service sent current health status to CDN Selection Service
Global DNS Load Balancer

Redirects DNS query to CDN A Load Balancer

Based on health and geo, DNS response points to CDN A LB IP

Protocol:DNS Response (UDP)
BeforeGlobal DNS Load Balancer awaiting CDN Selection decision
AfterUser receives DNS response pointing to CDN A LB
Config & Logging Service

Logs CDN selection decision and request metadata

Records that CDN A was selected for this user request

Protocol:REST API Call
BeforeConfig & Logging Service has no record of this request
AfterConfig & Logging Service stores selection and timing info
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────────────┐
│   Global DNS Load Balancer    │
└───────────────┬───────────────┘
                │ DNS Query (UDP)
                ▼
       ┌───────────────────┐
       │ CDN Selection     │
       │ Service           │
       └─────────┬─────────┘
                 │ REST API Call
                 ▼
       ┌───────────────────┐
       │ Health Monitor    │
       │ Service           │
       └─────────┬─────────┘
                 │ Health Status (gRPC)
                 ▼
       ┌─────────┴─────────┐
       │ CDN Load Balancers │
       │ ┌───────────────┐ │
       │ │ CDN A LB      │ │
       │ └───────────────┘ │
       │ ┌───────────────┐ │
       │ │ CDN B LB      │ │
       │ └───────────────┘ │
       └─────────┬─────────┘
                 │ HTTP Redirect
                 ▼
       ┌───────────────────┐
       │ Config & Logging  │
       │ Service           │
       └───────────────────┘
Design Rationale

This Multi-CDN architecture uses a Global DNS Load Balancer to route user DNS queries to the optimal CDN based on geographic location and real-time health data. The CDN Selection Service queries the Health Monitor Service to get current health status of each CDN load balancer. The Global DNS Load Balancer then responds to the user with the IP of the healthiest CDN load balancer, ensuring maximum availability and coverage. All decisions and configurations are logged by the Config & Logging Service for audit and analysis. This design decouples health monitoring from selection logic and DNS routing, allowing dynamic failover and load distribution across multiple CDNs.

Primary Focus

✓

Practice

(1/5)
1. A collaborative document editing system must ensure that concurrent edits from multiple users are merged in real-time without conflicts or data loss. Which component is primarily responsible for resolving these concurrent edits to maintain consistency?
easy
A. A relational database with row-level locking to serialize edits
B. An Operational Transformation (OT) or CRDT engine that transforms or merges concurrent operations
C. A distributed cache like Redis to store the latest document state
D. A message queue that orders all edit events strictly by timestamp

Solution

  1. Step 1: Identify the role of conflict resolution in collaborative editing

    Concurrent edits from multiple users require a mechanism to merge changes without overwriting or losing data. Simple serialization or ordering is insufficient due to network delays and offline edits.

  2. Step 2: Understand why OT or CRDT is needed

    Operational Transformation (OT) and Conflict-free Replicated Data Types (CRDTs) are designed to transform or merge concurrent operations in real-time, ensuring eventual consistency without central locking.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    OT/CRDT engines merge concurrent edits without locking or strict ordering [check]
Hint: OT/CRDT merge concurrent edits without locking or strict order [OK]
Common Mistakes:
2. In a collaborative editing system, at step 4 of the request flow, the OT engine receives two concurrent operations from users Alice and Bob. What does the OT engine do at this step to maintain document consistency?
easy
A. Transforms Bob's operation against Alice's operation to preserve intention and order
B. Rejects Bob's operation and requests a retry to avoid conflicts
C. Queues Bob's operation until Alice's operation is fully applied to the document
D. Applies Bob's operation directly, overwriting Alice's changes

Solution

  1. Step 1: Understand OT engine's role at concurrent operation receipt

    The OT engine must handle concurrent operations arriving out of order or simultaneously and merge them without losing user intent.

  2. Step 2: Recognize OT transformation process

    OT transforms one operation against another to adjust positions and effects, preserving both users' intentions and maintaining consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    OT transforms concurrent ops to preserve intention and order [check]
Hint: OT transforms concurrent ops to preserve intention and order [OK]
Common Mistakes:
3. For a distributed counter requiring strong eventual consistency and minimal coordination, which architecture is best suited?
medium
A. Use sharded CRDT counters replicated asynchronously with conflict-free merges
B. Use a centralized counter service with distributed locks to serialize increments
C. Use a distributed database with linearizable transactions for each increment
D. Use a message queue with exactly-once delivery and synchronous aggregation

Solution

  1. Step 1: Evaluate coordination and consistency trade-offs

    Centralized locks (A) and linearizable transactions (C) impose coordination and reduce availability. Message queues with synchronous aggregation (D) add latency and bottlenecks.

  2. Step 2: Recognize sharded CRDT counters provide eventual consistency with no coordination

    They allow concurrent increments and asynchronous merges, fitting minimal coordination and strong eventual consistency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Sharded CRDTs enable coordination-free eventual consistency [check]
Hint: CRDTs avoid coordination, unlike locks or linearizable DBs [check]
Common Mistakes:
4. For ensuring exactly-once payment processing in a distributed payment system, which architecture is best suited given high throughput and fault tolerance requirements?
medium
A. Use an event-driven architecture with Kafka for event sourcing and idempotent consumers
B. Use a synchronous two-phase commit protocol across all services to guarantee atomicity
C. Use a centralized relational database with serializable transactions for all payment states
D. Use client-side retries with unique request IDs and eventual consistency in backend

Solution

  1. Step 1: Analyze architecture trade-offs

    Synchronous two-phase commit (Use a synchronous two-phase commit protocol across all services to guarantee atomicity) blocks and reduces throughput; centralized DB (Use a centralized relational database with serializable transactions for all payment states) limits scalability; client-side retries (Use client-side retries with unique request IDs and eventual consistency in backend) risk inconsistent states.

  2. Step 2: Evaluate event-driven approach

    Kafka event sourcing with idempotent consumers supports high throughput, fault tolerance, and exactly-once processing semantics.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka event sourcing -> scalable, fault-tolerant, idempotent processing [check]
Hint: Event sourcing with idempotent consumers scales best [check]
Common Mistakes:
5. At 10x scale, which component in an HTTP/3 deployment is most likely to become the bottleneck first and why?
hard
A. WebSocket servers because HTTP/3 does not support WebSockets natively
B. TLS handshake CPU load on servers due to QUIC's per-connection encryption overhead
C. UDP packet loss rate increases causing retransmissions and latency spikes
D. TCP connection limits because HTTP/3 uses TCP under the hood

Solution

  1. Step 1: Identify HTTP/3 transport and encryption

    HTTP/3 uses QUIC over UDP with built-in TLS encryption per connection, increasing CPU load for handshake and encryption at scale.

  2. Step 2: Eliminate other bottlenecks

    UDP packet loss is network-level, not server bottleneck; WebSockets are not natively supported by HTTP/3 but unrelated to scaling HTTP/3 itself; HTTP/3 does not use TCP.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    QUIC's per-connection TLS handshake CPU load limits HTTP/3 scale [check]
Hint: QUIC TLS handshake CPU load limits HTTP/3 scale first [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