Stage 3 · Build

Caching, Queues & Background Jobs

Cache Patterns

Apply cache-aside, write-through, stale-while-revalidate, key design, and stampede protection.

8 min readBuilding Backend ApplicationsBuild

Cache-Aside

Cache-aside is the most common caching pattern. The application checks the cache first. On a miss, it reads from the database and populates the cache. On writes, it invalidates the cache.

Gocache-aside-implementation.go

36 linesLn 1, Col 1Go

Cache-aside is simple: read from cache, miss means read from DB and cache, write means invalidate cache. The cache is a transparent optimization layer.

Write-Through

Gowrite-through-caching.go

13 linesLn 1, Col 1Go

Write-through updates the cache on every write. This ensures the cache is always fresh but adds write latency. Use for read-heavy data that must be immediately consistent.

Stale-While-Revalidate

Gostale-while-revalidate-pattern.go

42 linesLn 1, Col 1Go

Stale-while-revalidate serves stale data immediately while refreshing the cache in the background. Users never wait for a cache refresh. The stale cache has a longer TTL as a fallback.

Key Design

Good cache keys are descriptive, unique, and include version information. Use colons as separators. Include the entity type and ID.

user:123 — simple entity cache
user:123:profile — specific view of an entity
user:123:permissions — nested data
v1:user:123 — versioned key for schema changes
lock:order:456 — distributed lock
rate:api:user:123 — rate limiter counter

Cache Stampede

A cache stampede happens when many requests hit a cache miss simultaneously and all try to rebuild the cache. This can overwhelm the database. Use locks or singleflight to prevent it.

Gousing-singleflight-to-prevent-stampede.go

34 linesLn 1, Col 1Go

singleflight coalesces concurrent requests for the same key into a single database query. All waiting goroutines receive the same result. This prevents stampede.

Cache Invalidation

There are two hard things in computer science: cache invalidation and naming things. The key insight is to invalidate eagerly on writes rather than relying on TTL alone.

Gocache-invalidation-strategies.go

18 linesLn 1, Col 1Go

Delete all related cache entries on write. This is simpler and more correct than trying to update cache entries. The next read will rebuild the cache from the database.

TTL is your safety net

Even with eager invalidation, always set a TTL on cache entries. If invalidation fails (Redis is down, code bug), the TTL ensures stale data expires eventually. This is your defense in depth.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.