references/architecture-patterns.md

# Architecture decisions for dependable data platforms

## Decision sequence
1. Business contract and freshness/latency objectives.
2. Source semantics: append-only, update/delete, CDC ordering, replay horizon.
3. Data volume, peak throughput, source rate limits, RPO/RTO and cost guardrails.
4. Trust boundaries: PII/tenant policy, regions, access, lineage.
5. Consumer grain and correctness invariants.

## Fit-to-need patterns
- **Scheduled batch**: sufficient for daily/hourly updates, replayable windows and lower operating overhead.
- **Incremental microbatch**: changed partitions/windows, bounded late arrivals, idempotent target upserts.
- **CDC**: authoritative source log positions, initial snapshot boundary, update/delete propagation and deduplication.
- **Streaming**: justified for latency targets that batch cannot meet; state and checkpoint ownership.
- **Lakehouse**: raw immutable/replayable landing + validated conformed tables + stable consumer models.
- **Warehouse ELT**: staged source contracts + tested transformations and marts, avoid unproven custom infrastructure.

Use a DAG/data-flow diagram with ownership, inputs, outputs, state stores and failure/retry boundaries. Specify how newly arrived vs changed vs deleted records reach consumers. Choose architecture with the simplest operational recovery model.