Pattern · Draft
Materialized View
Precompute a read-optimized projection so queries stay fast without recomputing on every request.
Status
Draft
Implemented by
Architecture
Source changes update a read-optimized projection asynchronously. Queries read the projection directly and may see stale data. A separate rebuild path regenerates the derived view from the source of truth.
Draft: this pattern is captured but not yet reviewed. The forces, trade-offs and failure modes below are a working position, not a finished one.
The problem
Reads that span several entities or aggregate over time are expensive to compute on demand. In a NoSQL store with no joins, doing that work per request pushes latency and cost straight into the user path, and the query shapes rarely match the write model.
The solution
Maintain a denormalized projection, updated as the underlying data changes, and read from the projection directly. Treat it as derived data with an owner, a rebuild path, and a way to detect drift, never a second source of truth.
Forces
What pulls against what.
- Read latency against write-path complexity
- Eventual consistency against availability
- Storage cost against repeated compute cost
- Rebuild and replay capability
On AWS
- DynamoDB Streams
- EventBridge
- Lambda
- DynamoDB GSIs
- AppSync
Trade-offs
- Faster, cheaper reads and query shapes tuned to the screen or use case
- Adds write-path work and a second artifact to keep correct
- The projection lags the source; callers must tolerate staleness or read the source when they cannot
When not to use it
- The data changes constantly and is read rarely
- Strict read-after-write is a requirement
- The projection is trivial and cheap enough to compute on demand
Failure modes
How it breaks when it breaks.
- Silent drift between source and projection with no reconciliation
- Dropped or duplicated change events leaving holes
- No rebuild path, so a schema change means permanent inconsistency