Back to path
AdvancedLinkly · Project 9 of 12 ~9h· 5 milestones

Go global with edge caching and geo-routing

Continues from the last build: It runs in one region now, so every redirect for a user on the other side of the planet pays a 200ms+ round trip before the app tier even sees the request.

Last rung you replicated the database and split reads from writes, and the numbers finally looked good, inside us-east-1.

CDN architectureAnycast and geo-DNS routingCache-Control and HTTP caching semanticsEvent-driven cache invalidationData locality for writesOrigin shieldingCapacity math for global trafficFailure-mode reasoning for caches
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

A defended edge-caching and geo-routing design: a CDN/anycast topology diagram, an ADR on cacheability and invalidation, a geo-routing scheme that keeps writes coherent, and capacity math proving the origin-load and latency wins, all without ever assuming the cache never misses.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

adr/0009-edge-caching-geo-routing.mdmarkdown
# ADR 0009: Edge caching and geo-routing for redirects

## Status
Proposed

## Context
- Cross-region latency today: <fill in from your ping tests, e.g. 180-320ms>
- Peak redirect QPS: <carry forward from rung 3/4 math>
- Which responses are idempotent GETs vs mutating writes: <list them>

## Options considered
1. Do nothing, accept latency for distant users.
2. Deploy read replicas per region only (data layer, no edge).
3. Add a CDN + geo-DNS/anycast layer that caches cacheable GETs at the edge.

## Decision
<State which option, and why, in one paragraph.>

## Consequences
- Positive: <latency win, origin load reduction>
- Negative: <staleness window, invalidation complexity, added moving part>
- Follow-up work: <e.g. purge queue, monitoring for hit ratio>

Reading this file

  • ## ContextGround the decision in your own numbers, not hypotheticals, pull the QPS and latency straight from earlier rungs.
  • Peak redirect QPS: <carry forward from rung 3/4 math>Reuses the capacity math from the reads-scaling rung so this ADR does not float free of the rest of the system.
  • ## Options consideredAn ADR without alternatives is just an announcement, list what you rejected and why.
  • ## DecisionOne paragraph, one option, no hedging, this is what future-you and the on-call engineer will actually read.
  • - Negative: <staleness window, invalidation complexity, added moving part>Every cache buys speed by selling freshness, name the exact cost you are accepting.

Fill in Context, Options, Decision, Consequences before writing any config.

That's 1 of 8 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Decide what is actually cacheable at the edge

    4 guided steps

    The single most common edge-caching mistake is caching the wrong thing, either something that changes underneath the cache (an updated redirect target) or something with per-request meaning (an authenticated API call). Getting this classification right before touching any CDN config is what keeps the rest of the rung honest.

  2. 2

    Design the geo-DNS/anycast and CDN topology

    4 guided steps

    A CDN with no routing intelligence in front of it just adds a hop, the geo-routing layer is what actually gets a Singapore user to a nearby PoP instead of the origin region.

  3. 3

    Design event-driven cache invalidation

    4 guided steps

    TTL-only invalidation means every edit has a silent staleness window equal to the TTL, for a link that might get shared minutes after being fixed, that window is unacceptable; an explicit purge event closes it down to the propagation delay of the queue instead.

  4. 4

    Keep writes coherent: route by data locality, not by nearest PoP

    4 guided steps

    Geo-routing is built to make reads fast by ignoring where the data physically lives, that is exactly wrong for writes: a write served by whichever region is nearest, without checking where the primary is, either fails against a read-only replica or silently forks data if that region also happens to have its own write path.

  5. 5

    Design for cache misses and origin protection

    4 guided steps

    The single most dangerous assumption in this whole rung is that the CDN never misses. It misses on cold codes, after every eviction, after every purge, and catastrophically all at once if a popular PoP's cache is flushed or a deploy resets it; the origin has to be sized and shielded for that reality, not for the best case.

What's inside when you start

3 starter files, ready to clone
5 guided milestones
5 full reference solutions
8 code blocks explained line-by-line
5 "is it working?" checks
5 interview questions it prepares you for

You'll walk away with

ADR 0009 defending which responses are cacheable at the edge and why, with the read/write ratio and QPS baked in
An updated architecture diagram showing geo-DNS/anycast, multiple CDN PoPs, the invalidation queue, and the single write path
A capacity worksheet with origin QPS and latency improvement under normal and degraded (miss-storm) hit ratios
A written invalidation design (trigger, fan-out, ordering guard, TTL fallback) for cache purge on link update/delete
A write-locality design note explicitly routing mutations to the primary region regardless of client geography

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building