Serving Snapshots

Summary

Serving snapshots are published read models that let operational consumers use lakehouse-derived context without directly owning the analytical joins that created it.

Problem

Operational UI and API code need predictable, low-friction reads. Raw lakehouse tables often need freshness checks, joins, windowing, identity resolution, or curated filters before they are appropriate for repeated interactive use.

Principle

Serve from a stable projection when a workflow depends on lakehouse-derived context. Keep the projection contract explicit and refresh it through a known publish path.

Platform Shape

The architecture docs recommend serving projections when interactive surfaces need lakehouse data. The lakehouse docs mention serving snapshots as part of the core incremental DAG sequence. The publish job is the operational boundary that turns analytical products into read models for consumers.

A serving snapshot is not a substitute for domain state. If a user changes workflow status, approves an action, or repairs an issue, that belongs in OLTP state owned by the relevant service.

Source Evidence

• docs/reference/architecture.md
• docs/domains/lakehouse.md
• jobs/lakehouse/publish_serving_snapshots/run.py

Related Reading

• docs/engineering/architecture/oltp-vs-analytics-boundaries.md
• docs/engineering/architecture/explicit-publish-steps.md