How would you compare cache-aside, read-through, and write-through caching?

In production I state which store is authoritative and the freshness promise users actually need. A distributed cache is still a fallible replicated view, not automatically a transaction participant with the database. If write-through cannot atomically update both systems, I define ordering, idempotency, an outbox or change feed when appropriate, and reconciliation for partial success. For cache-aside I usually commit the source and invalidate rather than overwrite, because a concurrent reader can otherwise repopulate an older value after the write; versioned keys or compare-and-set can tighten the window when needed. Negative caching has a short TTL and never crosses tenant or permission scope. Fail-open fallback to the source is bounded so a cache outage does not stampede the database; some workloads must shed load instead. Metrics cover hit ratio by use case, miss and fill latency, origin load, stale-read reports, evictions, invalidation failures, hot keys, and repair lag. I choose no cache when hit rate, sensitivity, or consistency cost does not justify it. The simplest operable flow that meets the freshness contract is better than a sophisticated pattern whose failure states nobody can explain.