Views as static files

This is a CQRS read model whose store is a bucket. The write side publishes an event per change, often through a transactional outbox so a saved change can’t lose its event. A projector, typically a serverless function triggered by the event, loads what it needs, renders every view the change touches and writes each one as a whole object. On Amazon S3 a PUT that overwrites a key is atomic and strongly consistent: a reader gets either the old object or the new one, never part of each.

The CDN then has to let go of the old copy. A short max-age caps staleness without any extra calls; path or tag invalidations drop copies right away but cost per path beyond a free tier on CloudFront; versioned file names avoid invalidation entirely. Microsoft’s guidance for materialized views applies directly: keep serving the last complete version until the new one is built and checked, and alert when the newest view is older than you can accept, because a lost event means a view that is silently stale.

Pick it for public, read-heavy pages with a handful of shapes. Avoid it when views depend on who is asking, or when one write would rewrite thousands of files.