State vs Computation

The pattern: separate where data lives from where work happens. Computation scales horizontally — more workers, cheap, ephemeral. State scales differently — replicas, careful consistency, durable. Coupling them, by putting state inside compute, limits both: you can’t autoscale without losing data, and you can’t recover state without replaying compute. Pulling them apart is what makes pods restartable, lakehouses multi-engine, and serverless viable.

The trade-off: operational simplicity vs. flexibility. A monolith with co-located state is easier to reason about for small systems — one process, one disk, one backup. Splitting state from compute (services + DB; lakehouse separating storage from compute engines) costs more upfront (network in the hot path, transactional boundaries to manage) but unlocks independent scaling, multi-engine reads, and easier blue/green deploys. The 2020s lakehouse insight — “storage is dumb cheap; compute is expensive; separate them” — is this pattern made canonical at data-platform scale.

[Deepen Year 3 Phase 15 — the lakehouse insight is the canonical 2020s example.]

Related patterns

• control-loops — desired state lives in storage; compute (controllers) drives toward it.
• layering-and-abstraction — splitting state from compute is layering applied to data systems.
• caching — caches re-couple compute and state for speed; understand what you gave up.
• replication — once state is separated, it has its own replication topology.
• partitioning — separated state needs its own scale-out strategy.
• oltp-vs-olap — different compute engines reading the same separated state.
• immutable-infrastructure — works only because state is not in the immutable nodes.
• First touched: Year 1 Phase 7: Kubernetes + GitOps (triage as stateless pod + Postgres).
• Deepened in: Year 3 Phase 15: Lakehouse.
• Projects where it lives: triage, basecamp (Tier 3 lakehouse).