LEARN. PRACTICE. GROW.Concept and mechanism
A cache reduces repeated work when data and tolerated staleness allow it. In cache-aside, a miss leads to a backing-store read and later population. Writes need an invalidation strategy, but the pattern does not promise automatic consistency across all copies. Local caches can diverge between instances. Separating read and write models with CQRS does not by definition require separate databases or event sourcing. A projection can serve efficient queries while lagging behind writes. The contract should explain that freshness and how the application confirms a recent operation.
Guided application
In a fictional example, one customer generates most operations. Hashing customer identity distributes customers but does not automatically split that hot customer across several partitions. Review the key, dominant queries, ordering, and rebalancing cost. A queue can absorb a burst and protect consumers if the aggregate rate respects downstream capacity. If average arrival continuously exceeds completion, delay grows. Adding unbounded consumers may merely move saturation to the database. Compare these options against the measured problem: caching for reuse, partitioning for data and load distribution, queues for rate decoupling, without assigning one mechanism guarantees that belong to another.
A good overall cache-hit ratio can hide a hot customer or stale reads in a critical flow.
Common pitfalls
Cache as always-current truth; CQRS as mandatory dual databases; hashing as automatic tenant splitting; unbounded queues.
Related topics: Requirements and architecture decisions · Capacity and latency · Data and consistency
Measure distribution, freshness, and delay beyond total throughput.
Reference: Sharding pattern · System design patterns; PostgreSQL18 scoped examples; primary guidance consulted 2026-09-30