Cache-Aside API

What I’m planning to build

A minimal Go HTTP API that reads and writes items through Redis using the cache-aside pattern: check cache first, fall back to the backing store on miss, populate cache on read, invalidate on write.

Why this pattern

Cache-aside is the default in most services I touch, but “default” does not mean “simple under failure.” TTL drift, thundering herds, and stale reads after writes are where teams get burned. A tiny reference implementation makes those trade-offs concrete.

What it covers

• Redis-backed cache layer with configurable TTL
• Prometheus /metrics for cache hits, misses, and latency
• Docker Compose stack (Redis + API on port 8080)
• Unit tests with miniredis — no Docker required for CI

Connection to my day job

Platform engineering is often about making the right thing easy — caching, rate limits, circuit breakers. This repo is where I keep the pattern honest: idempotent handlers, observable hit rates, and clear separation between cache and source of truth.

Repo

Source lives in the sandbox monorepo under projects/cache-aside-api/.