OLTP Versus Analytics Boundaries
Summary
OLTP state and analytics state answer different questions. The platform keeps them separate so interactive work stays low-latency, auditable, and repairable while analytical truth stays rebuildable.
Problem
Analytics tables are attractive because they contain rich context. If UI/API code reads them directly for interactive state, the platform quietly couples operator workflows to historical transforms and batch freshness. If pipelines write review state directly, deterministic ETL becomes a hidden business workflow engine.
Principle
OLTP owns interaction and repair. Analytics owns history, canonicalization, and facts. Crossing the boundary should be explicit and usually happen through a service or publish step.
Platform Shape
The lakehouse document defines bronze, silver, and gold as the medallion layers for raw source data, canonical entities, and curated facts. The architecture document defines domain schemas as the home for cases, issues, review tasks, queues, approvals, locks, and read models.
When a UI needs lakehouse-derived context, the preferred path is a service or serving snapshot. When a pipeline discovers ambiguity, it should publish a signal or produce data that a stateful service can turn into an issue.
Source Evidence
docs/reference/architecture.mddocs/domains/lakehouse.mdservices/lkci_lakehouse
Tradeoffs
The boundary can feel slower during exploratory development. It becomes valuable when the same fact needs to support jobs, review, reporting, and future agent surfaces without each caller learning warehouse internals.
Related Reading
docs/engineering/architecture/serving-snapshots.mddocs/engineering/architecture/explicit-publish-steps.md