# Data-intensive systems

Data-intensive applications rarely need one universal database. They need a
coherent semantic model and explicit movement among transactional, analytical,
search, streaming, object, graph, and vector realizations.

## Begin with data obligations

Declare nominal records, invariants, ownership, consistency, transactions,
query shapes, change semantics, classification, residency, retention,
deletion, throughput, latency, RPO, and RTO. Planning can then compare physical
families without changing application meaning.

Do not start by naming an engine and reverse-engineering its current schema
into the contract. Provider-specific tuning remains possible through typed
configuration attached to the selected realization.

## Separate systems of record from derived views

A durable transactional store may feed search indexes, analytical tables,
caches, feature vectors, graph projections, and materialized views. Each
derived view records:

- its source schema and cursor;
- conversion and loss policy;
- freshness and consistency contract;
- rebuild and backfill path;
- privacy and deletion propagation;
- provider, cost, and observation evidence.

A view can be disposable only when the source and deterministic rebuild path
meet its recovery contract.

## Plan movement as first-class work

Imports, exports, CDC, replication, rebalancing, compaction, reindexing,
backfill, archival, and deletion are typed operations. They carry checkpoints,
resource limits, authority, schema mappings, reconciliation, and exact
postconditions.

For online changes, use a bounded transition: expand, backfill, validate,
switch readers, switch writers, observe convergence, and remove the retired
path. Every overlap ends under an explicit condition.

## Make global claims local and composable

Strong consistency or total order exists only inside the authority domain that
provides it. Cross-region and cross-provider systems identify the scopes in
which ordering, atomicity, uniqueness, and freshness hold.

Conflicts use domain-owned resolution or an explicit reject/manual path. A
last-writer-wins timestamp is not silently substituted for business meaning.

## Prove operations, not labels

A provider that claims durability also proves recovery behavior. A replicated
store proves fencing and repair. A multi-tenant store proves isolation and
resource fairness. A backup provider proves restore compatibility. A vector or
search provider proves the declared quality and freshness bounds.

Planning selects only claims supported by exact, fresh, admitted evidence.

## Example

Illustrative planning output explains a rejected data realization:

```text
requirement durability acknowledged
accepted one.data.postgres#Managed@1
rejected one.data.memory#Ephemeral@1: durability unsatisfied
```

See [data and state](/one/model/data) and
[recovery and continuity](/one/lifecycle/recovery), then follow the
[data-backed service recipe](/one/examples/data-service) or
[analytical, search, and vector projection recipe](/one/examples/analytical-search-data).