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.” Time-to-live (TTL) drift, the thundering herd (from what I’ve learned, when the cache expires and everyone hits the database at once), 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 Continuous Integration (CI))

Connection to my day job

Platform engineering is often about making the right thing easy: caching, rate limits, circuit breakers. This repo keeps the pattern honest: handlers safe to retry, observable hit rates, and clear separation between cache and source of truth.

Repo

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