Cloudflare System Design Interview: What They Test

System design is one round of Cloudflare's virtual onsite, and it runs about an hour on a shared drawing surface. The coding and debugging rounds mostly decide whether Cloudflare hires you at all. This round does something different. It leans on the level you land at. The more senior you are, the more it weighs. A junior candidate may get a light, practical design or a design-flavored coding task. Senior and staff loops sit the full round. They are read closely on it. Reports point to a medium-to-hard prompt and an interviewer who drives the conversation. Seniority gets calibrated here.

The Cloudflare angle

The signature constraint here is "host it yourself." Cloudflare runs its own network rather than renting one, so an answer that reaches for a managed cloud service by name tends to draw a redirect. One candidate report has an engineer sketch an ingestion pipeline on S3, Glue, and Athena. Then came the ask: redo it on their own hardware. No AWS, no GCP. Managed services are not wrong in general. This interviewer wants to see you name the primitives underneath. Think Anycast PoP routing, your own storage, a log like Kafka or Pulsar, and config pushed to the edge the way Cloudflare's Quicksilver does. Reason from the pieces, not from a provider's product catalog.

The round, and the two forms it takes

First, a word on what a point of presence is, since it recurs everywhere below. A PoP is one of the data centers Cloudflare runs in more than 300 cities, and every service the company sells runs in all of them at once. That fact shapes the round. The prompt arrives in one of two forms. The first is a canonical edge product: design a content delivery network, a DNS service, an edge key-value store. The second is a walk through a system you built. It is sometimes framed as a project retrospective, and the interviewer probes how it scales and why you made each call. Candidates who got the second form tend to rate it well, because it rewards depth on something you know cold. The grid below is the shape of the round. Cloudflare does not publish a question list, so read it as a steer.

• The round: ~60 min, one slot. A single design round in the virtual onsite, medium to hard, on a shared drawing surface. Interviewer-driven, with one or two areas taken deep rather than a broad tour. Some teams add a team-specific technical round on top that can carry its own design-flavored question.
• Two forms: Edge product or project deep-dive. Either a canonical Cloudflare-shaped system (CDN, DNS, edge KV) or a scale-probing walk of a system you built. The second rewards genuine depth, so come ready to defend an architecture you owned.
• Level skew: Heavier for senior and staff. Junior loops (roughly the P1 to P2 band) often get a lighter, practical design or a design-flavored coding task. Senior and above (P3 and up) sit the full round, and a weak showing can pull the offered level down even when the coding went well.
• The constraint: No managed cloud. The most distinctive rule of the round: build it on your own infrastructure. Name Anycast, PoPs, owned storage, Kafka or Pulsar, edge config distribution. A design leaning on a cloud provider's managed services gets pushed back toward the primitives.

Two habits of thought run through every prompt. The first is thinking at the edge instead of in a single region. Work happens close to the user, in the PoP their packets landed in, and only the requests that cannot be served locally travel back to a core. The second is designing for a network that is always partially broken. Something, somewhere, is always down. Across 300-plus PoPs, some machine or link is degraded at any moment, sometimes a whole facility. A happy-path diagram is never enough. The interviewer will ask what happens when a PoP falls out or a region goes dark, and answering that cleanly is what the round is really checking for.

The Cloudflare angle

Anycast is the one idea to internalize before the round, because four of the five designs lean on it. Anycast is a routing trick: many machines in many cities all announce the same IP address to the Internet, and the network delivers each user's packets to whichever one is closest. That single mechanism puts a CDN edge near every user. The same trick places a DNS resolver and a DDoS-absorbing front door right beside it. The user never picks a location. It is also why a Cloudflare design rarely needs a global load balancer as a separate box. The routing layer already spreads traffic across PoPs and steers around a failed one. Get comfortable saying why Anycast buys you low latency and failover at the same time, and you can reuse it in the CDN, DNS, DDoS, and rate-limiter answers.

The edge request path most designs share

Almost every Cloudflare design routes a request the same way at the top, so it helps to carry one mental picture. The user lands in the nearest PoP by Anycast. That PoP tries to answer locally. It serves from cache or from code running at the edge, and falls back to the origin or a core data center only when it has to. The color legend for the diagram: blue is the user, violet is edge compute and services, and green is stored state.

The instinct to carry from this picture is simple. Keep it local. Answer as close to the user as you can, and make the trip back to origin the exception. A CDN wins on cache hit ratio. DNS wins by answering from a nearby resolver instead of chasing an authoritative server. A rate limiter wants to decide inside the PoP, no round trip to a central counter. So when a design forces every request back to one core, that is usually the first thing to fix. The interviewer is watching for whether you notice on your own.

The shapes Cloudflare asks

The prompts cluster into a handful of distinct shapes. The chart orders them by how often each comes up, blending the products candidates walk in expecting with the edge-flavored distributed problems that show up in firsthand accounts. The families below each get a full worked design; a long tail (an edge log pipeline, a distributed scheduler, a batch-ingest job) makes up the rest and shares machinery with these.

Look at the spread. Each shape forces a different hard problem. Caching is a read-heavy distribution problem: route to the nearest copy, invalidate globally the instant content changes, and protect the origin behind a shield tier. DDoS mitigation is a traffic-analysis problem: absorb or challenge attack traffic measured in terabits per second while keeping legitimate requests fast. Rate limiting is a distributed-counting problem: enforce a per-key limit across hundreds of PoPs with no central coordinator on the request path. DNS is a global-lookup problem: answer at massive query rates with aggressive caching, correct TTLs, and DNSSEC. Edge key-value is a distributed-storage problem: replicate reads to every PoP while deciding how stale a value may be.

The Cloudflare angle

Reason at Cloudflare's actual magnitudes, because they change which answers survive. The network spans 300-plus cities and fields tens of millions of requests per second. The numbers are not decoration. The largest DDoS attacks it reports are measured in terabits per second, not gigabits. At those numbers a central database on the request path is out. A scheme that gossips exact per-key counts between every pair of PoPs does not fit in the time budget. And "just add a queue" has to answer where that queue lives when the queue itself is under attack. Every worked design that follows states its scale first and lets the architecture follow from it. That is exactly the move the interviewer rewards. Say the big number out loud early. Then design to it.

The worked designs

Five designs follow, one per shape above, in frequency order. Start with the content delivery network. It is the fullest use of the shared edge path, and it grounds the Anycast, tiered-cache, and origin-shield vocabulary the other four reuse.

Each design assumes the fundamentals from the System Design course. Lean on the scaling playbook for read and write paths, and the toolbox for when to reach for a log, a cache, a queue, or an index. These pages stay on the edge-first design Cloudflare tests and leave the general mechanics to those.

Common questions