Bird
Raised Fist0

Cloudflare Route Leak - How One Config Took Down the Internet

HLDhardInterview freq: rare
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Config Management

Pushes new route filter config

Sends updated route filtering rules to Route Collector

Protocol:gRPC
BeforeRoute Collector uses previous route filter config
AfterRoute Collector has new route filter config loaded
Route Collector

Ingests BGP route updates

Receives routes from peers including leaked routes

Protocol:BGP
BeforeRoute Collector has no new route updates
AfterRoute Collector buffers new routes and publishes to Kafka
Kafka

Queues route update events

Durably stores route updates for downstream processing

Protocol:Kafka protocol
BeforeKafka queue empty for this route topic
AfterKafka queue contains new route update messages
Route Validation Service

Consumes and validates routes

Checks routes against policies; misconfiguration allows leak

Protocol:Kafka consume
BeforeValidation service has no pending route updates
AfterValidation service marks leaked routes as valid incorrectly
Route Distribution (BGP Speakers)

Advertises validated routes externally

Sends leaked routes to external BGP peers

Protocol:BGP
BeforeBGP speakers advertise only valid routes
AfterBGP speakers advertise leaked routes causing route leak
Observability & Alerting

Detects abnormal route announcements

Triggers alerts on unexpected route leak patterns

Protocol:Internal monitoring
BeforeNo alerts on route leaks
AfterAlerts raised for route leak incident
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│    Config Mgmt        │
│  (Manages route rules)│
└────────────┬──────────┘
             │ Config push (gRPC)
             ▼
┌───────────────────────┐
│    Route Collector    │
│ (Ingests BGP routes)  │
└────────────┬──────────┘
             │ Kafka publish
             ▼
┌───────────────────────┐
│        Kafka          │
│ (Durable route queue) │
└────────────┬──────────┘
             │ Kafka consume
             ▼
┌───────────────────────────────┐
│    Route Validation Service    │
│ (Checks route correctness)    │
└───────────────┬───────────────┘
                │ Validated routes (gRPC)
                ▼
┌───────────────────────────────┐
│  Route Distribution (BGP Srv) │
│ (Advertises routes externally)│
└───────────────┬───────────────┘
                │ BGP updates
                ▼
┌───────────────────────────────┐
│  Observability & Alerting      │
│ (Monitors route anomalies)    │
└───────────────────────────────┘
Design Rationale

This architecture shows how a misconfiguration in Config Management propagates through the system. The Route Collector ingests BGP routes and publishes them to Kafka, ensuring durability. The Route Validation Service consumes these routes and applies filtering policies. Due to a config error, leaked routes are incorrectly validated and then advertised by Route Distribution to external peers, causing a widespread route leak. Observability & Alerting monitors route anomalies and triggers alerts once the leak is detected. This vertical flow highlights the critical role of validation and config management in preventing route leaks.

Primary Focus

✓

Practice

(1/5)
1. A system must guarantee that user-uploaded files are stored durably and retrievable even after server crashes. Which component best addresses this non-functional requirement?
easy
A. In-memory cache like Redis for fast access
B. WebSocket server for real-time upload progress
C. Load balancer to distribute upload requests
D. Distributed persistent storage like Amazon S3

Solution

  1. Step 1: Identify durability requirement

    Durability requires persistent storage that survives crashes, ruling out volatile caches.

  2. Step 2: Match component to durability

    Amazon S3 provides distributed, durable storage with replication and fault tolerance, fitting the requirement.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Persistent storage ensures data survives crashes [check]
Hint: Durability needs persistent storage, not cache or load balancer [check]
Common Mistakes:
2. A deployment system must ensure zero downtime during releases by switching traffic instantly between two identical environments. Which deployment strategy best fits this requirement?
easy
A. Rolling deployment updating servers one by one
B. Canary deployment with gradual traffic shifting to new version
C. Feature flags toggling new features on the same environment
D. Blue-Green deployment with instant switch of load balancer target

Solution

  1. Step 1: Identify zero downtime requirement

    Blue-Green deployment uses two identical environments and switches traffic instantly, ensuring zero downtime.

  2. Step 2: Eliminate other options

    Canary is gradual, not instant; Feature flags don't switch entire environments; Rolling updates cause partial downtime.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Blue-Green switches environments instantly for zero downtime [check]
Hint: Instant switch between identical environments is Blue-Green [OK]
Common Mistakes:
3. Without the consistent hashing ring metadata, what exactly breaks in a distributed cache system when a client requests a key?
medium
A. The cache nodes lose synchronization and data becomes corrupted
B. The cache node receiving the request cannot determine the correct node, causing request failure or indefinite retry
C. The client receives stale data from an outdated cache node
D. The system falls back to a centralized database for all requests, increasing latency

Solution

  1. Step 1: Role of consistent hashing ring metadata

    The ring metadata maps keys to nodes; without it, nodes cannot route requests correctly, leading to inconsistent data placement.

  2. Step 2: Consequence of missing ring metadata

    Without this metadata, nodes lose synchronization on key ownership, causing data corruption as writes go to wrong nodes; request failure (The cache node receiving the request cannot determine the correct node, causing request failure or indefinite retry) is secondary, and fallback (The system falls back to a centralized database for all requests, increasing latency) is not automatic.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Missing ring metadata causes data corruption due to lost key-node mapping [check]
Hint: No ring metadata -> lost key-node mapping -> data corruption [check]
Common Mistakes:
4. You must choose between a monolithic architecture and microservices for a system with rapidly evolving features and a small team. Which choice best justifies your design decision to the interviewer?
medium
A. Choose microservices because they always scale better regardless of team size
B. Choose monolith to reduce operational complexity and speed up feature delivery for a small team
C. Choose microservices to isolate failures even if it increases deployment overhead
D. Choose monolith because it requires no testing or CI/CD pipelines

Solution

  1. Step 1: Analyze team size and feature velocity constraints

    Small teams benefit from simpler architectures to reduce overhead and speed delivery.

  2. Step 2: Evaluate operational complexity of microservices

    Microservices add deployment and operational complexity, which can slow small teams.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Monolith reduces complexity, speeds delivery for small teams [check]
Hint: Small teams prefer monoliths for simplicity and speed [check]
Common Mistakes:
5. If the HTTP/2 connection's TCP layer experiences packet loss, what is the exact failure mode affecting multiplexed streams?
medium
A. All multiplexed streams stall due to TCP head-of-line blocking until lost packets are retransmitted
B. HTTP/2 switches to HTTP/1.1 fallback automatically to avoid stalls
C. The connection resets immediately causing all streams to fail
D. Only the lost stream stalls; other streams continue unaffected

Solution

  1. Step 1: Understand TCP head-of-line blocking impact

    TCP guarantees ordered delivery, so packet loss stalls all streams multiplexed on the connection until retransmission completes.

  2. Step 2: Eliminate incorrect failure modes

    Only one stream stalling is false due to TCP ordering; connection reset or fallback does not happen automatically.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    TCP loss stalls all HTTP/2 streams due to head-of-line blocking [check]
Hint: TCP loss stalls all HTTP/2 streams due to ordering [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