Materialised View Pattern
Maintaining a pre-computed, query-shaped copy of data so reads are cheap, at the cost of write amplification and staleness.
The pattern trades write-time work for read-time speed, and it is the correct trade whenever reads substantially outnumber writes — which describes most systems.
The forms it takes: a database materialised view refreshed on a schedule; a denormalised table maintained by triggers or application code; a search index built from a change stream; a cache populated on write; and the read model in a CQRS system, which is the same idea named differently.
The considerations that decide whether it works. Staleness: how out of date may the view be, and does the consuming interface communicate that honestly? Update mechanism: full periodic refresh is simple and does not scale; incremental maintenance from a change stream scales and is harder to get right. Rebuild: a view will need rebuilding after a defect, and if that takes eleven hours during which the feature is unavailable, the design is incomplete. Consistency: the view can diverge from the source through a missed event or a bug, so a reconciliation process is not optional — it is the thing that makes the pattern safe.
The failure most often encountered in production is silent divergence: the view has been subtly wrong for weeks, nobody noticed because it looks plausible, and the reconciliation job that would have caught it was never built. Building the rebuild path and the comparison check at the same time as the view is what separates a robust implementation from one that will erode trust.