Caching, Read Models and Polyglot Persistence

Caches (in-process and distributed) cut latency and database load for hot reads. Cache-aside is the default: read the cache, load from the database on a miss, and delete the key after writes commit. Correctness problems come from invalidation races, stampedes on hot keys, penetration by nonexistent keys and synchronized expiry. Each has a standard defence.

9 min 1 code practice

A materialized view stores a query's result so expensive aggregations become cheap reads. PostgreSQL refreshes them fully (REFRESH MATERIALIZED VIEW CONCURRENTLY keeps them readable); incremental maintenance uses summary tables updated by triggers, jobs or event consumers. CQRS generalises this: writes go to a normalized model, reads come from projections built for each screen.

8 min 1 diagram 1 code practice

Real systems combine PostgreSQL, Redis, Kafka, Elasticsearch, object storage and sometimes Cassandra or MongoDB. For each piece of data, name the source of truth and the synchronisation mechanism (same transaction, outbox/CDC, cache-aside, batch) for every copy, with its consistency, durability and staleness budget.

8 min 1 code practice

Recurring schema patterns: soft delete (mark instead of remove), history and audit tables (who changed what, when), temporal tables with validity ranges (what was true at time T), snapshots, event sourcing (store events and derive state), plus the repository and unit-of-work patterns for application access. Each solves a real need and adds cost.

9 min 1 code practice