System Design LiveHands-on challenges

Reverse-Proxy Caching

All challenges

Reverse-Proxy Caching

Your content site renders articles through an nginx reverse proxy. The backend render is expensive — every GET/articles/<id> costs about 600ms of real work — but the responses are completely cacheable: the same article always renders the same body, and the backend even says so with Cache-Control: public, max-age=30. nginx ignores it, so every request hits the backend, which is now pegged at its CPU limit — latency climbing, requests timing out under load, all to re-render the same ten articles over and over.

System Architecture

HTTP :80every requestClient SimulatorNGINXContent API

Your task

Enable proxy caching in nginx so repeated article reads are served from the proxy, the backend re-renders an article only when its cached copy expires, and every request is fast and successful.

You edit only nginx.conf (the nginx workload, cloned into your dev-vm):

  • The backend answers at content-api:80, and /var/cache/nginx exists in the image for your cache to live in.
  • Commit + push → the platform rebuilds the image and restarts nginx.
  • A broken config fails nginx at startup — check the deployment logs.

Pass criteria

The grader watches ~1 minute of live traffic. All three must hold:

  • No failed requests — every request gets a 2xx (no errors, no timeouts).
  • Most responses are fast — under 200ms, which at this render cost only a cache hit can be. A healthy cache serves the overwhelming majority fast; the bar is a sustained fast rate no uncached setup can reach.
  • The backend is offloaded — content-api CPU stays low, rendering each article ~once per 30s instead of on every request.

Where to look

  • Monitoring — content-api CPU falls off a cliff the moment caching works.
  • API Stats — request rate and latency as the simulator sees them.
  • Logs — the simulator's summary prints fastPct (your live cache hit ratio). From the dev-vm, curl -i http://nginx:80/articles/3 twice shows a MISS become a HIT (add an X-Cache-Status header in your config to make it visible).

Submit once fastPct has settled high for a clean minute — submissions are free, so your best score counts.

  • Two directives are the core: proxy_cache_path … keys_zone=… (http level) and proxy_cache … (location level). nginx honours the backend's Cache-Control by default.
  • Mind the default cache key — and what a querystring does to it.
  • add_header X-Cache-Status $upstream_cache_status always; shows HIT/MISS per response.