Caching Edge Proxy with Tag-Based Purge for Small Hosting Providers

The problem: caching is easy until content changes

Online stores and news sites are mostly read-heavy, which makes them ideal for caching at the edge. The hard part is invalidation. When a shop changes a product price, every page showing that product (the product page, three category pages, the home page carousel, search results) must stop serving the old price quickly. Purging by URL misses pages. Purging everything throws away the cache and floods the origin, which is exactly when a small store's server falls over.

Large CDNs solve this with tags: Fastly calls them surrogate keys and Cloudflare supports Cache-Tag purging, where the origin labels responses and a single purge clears every object with that label. Cloudflare has also written about Quicksilver, its system for pushing configuration to every edge location quickly, which is a useful model for purge distribution.

Regional hosting providers and web agencies would like to offer a CDN add-on to their customers, with their own nodes close to their users and their own pricing, but building one from open source parts is hard, and tag purge across nodes is the piece usually missing.

What already exists and the gap

• Cloudflare and Fastly provide tag-based purge on global networks as hosted services.
• Bunny.net offers a lower-cost CDN with pull zones and purge features.
• Varnish is a powerful open source cache that supports banning by header on a single node; multi-node purge coordination is left to the operator.
• Nginx proxy caching is widely used but has no built-in tag purge in the open source version.

The gap is a small, self-hostable edge with tag purge as a first-class, multi-node feature, and clear guarantees about how fast and how reliably a purge lands.

What you build

• Edge node: an HTTP reverse proxy with a two-tier cache, correct handling of caching headers, coalescing and stale serving.
• Tag index: per node, a mapping from tag to cached object keys, updated on insert and eviction.
• Purge service: accepts purge requests from origins, assigns them a sequence number, and publishes them. Each node applies purges in order, records the last applied sequence and catches up after being offline.
• Routing: GeoDNS sends users to the nearest node; health checks remove failed nodes.
• Observability: metrics for hit ratio, origin requests, latency and purge lag per node.

The technically interesting part

The hard problem is purge correctness in a distributed system. A purge must reach every node, including one that was offline or partitioned; it must not be undone by a response that was in flight from the origin before the purge and arrives after it (a classic race); and it must be fast. You will need ordered purge sequence numbers, a rule that rejects inserting objects fetched before the latest relevant purge, and catch-up replay. Show evaluators a test that partitions a node, issues purges, heals the network and proves no stale object is served afterwards, alongside cache mechanics like coalescing under a thundering herd.

How to evaluate it

• Correctness: an automated suite covering HTTP caching semantics, plus fault injection (node restart, network partition, delayed origin responses) with zero stale reads after a purge completes.
• Purge propagation: time from purge request to every node applying it, median and worst case, across regions.
• Performance: requests per second, latency percentiles and memory use compared with Varnish or Nginx on the same hardware.
• Origin offload: origin request rate with and without the edge during a simulated sale with load generated by a load testing tool.
• Hit ratio: over a week serving a real or replayed traffic pattern.

Suggested plan

1. Semester 1, weeks 1 to 5: single-node proxy with memory cache and correct header handling.
2. Weeks 6 to 10: disk tier, eviction, coalescing and stale serving.
3. Weeks 11 to 14: tag index and single-node purge; benchmark against a baseline.
4. Semester 2, weeks 1 to 5: purge log, multi-node distribution and catch-up.
5. Weeks 6 to 9: GeoDNS deployment in three regions and fault injection.
6. Weeks 10 to 14: full evaluation and write-up.

Path to a product

The first customer is a regional hosting company or web agency that hosts online stores and wants to sell a CDN add-on under its own brand. Sell it as licensed software with support per node, or run it for them and charge per terabyte served. A store platform plugin that emits tags automatically makes adoption much easier.

Scope warning

Do not build DDoS protection, a web application firewall, image optimisation or TLS certificate management beyond using an existing library. Do not aim for dozens of locations; three nodes prove the design. HTTP/3 is out of scope.

Learn what you need on Sefism

• System design roadmap : caching, consistency and distributed coordination.
• System design cheat sheet : CDN, cache invalidation and replication patterns at a glance.
• Beej's Guide to Network Programming : sockets and networking foundations for a proxy.
• Everything curl : inspect caching headers and conditional requests while testing.
• Grafana k6 Documentation : generate the load for offload and thundering herd experiments.

Get help with this idea

The purge race and its test are what examiners will probe, so walk through them with a mentor early. A mentor can help you set the scope, pick a stack you can finish with, and design an evaluation your examiners will respect. The build is yours; the guidance is on scope, stack and evaluation. New here? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session