Architecture

BitVault is designed as a modular monolith first (ADR-0001): all logic ships in a single bitvaultd binary in v1, with hard module seams that make future service extraction mechanical rather than speculative. Every architectural decision is evidence-driven — services are extracted only when a forcing function is demonstrated, never by anticipation.

Contents

Document Description
System Overview C4 context + container diagrams, the three planes, canonical flows
Data Model ER diagram, key invariants, storage strategy per layer
Service Boundaries Ownership rules, per-module detail, extraction criteria
### [System Overview →](/architecture/overview.html) C4 Level 1 and Level 2 diagrams. Upload, download, sync, and event flows. The three planes (control / data / async).
### [Data Model →](/architecture/data-model.html) Entity-relationship diagram across all 14 entities. Six correctness invariants. Per-layer storage strategy and multi-tenancy model.
### [Service Boundaries →](/architecture/service-boundaries.html) Ownership rules for all ten logical modules. Per-module boundary rationale. Extraction forcing functions and anti-patterns.

:::note ADR-0001 — Modular Monolith First v1 ships as a single bitvaultd binary. The module seams are the same seams you would cut to extract services — which means extraction is a deployment change, not a rewrite. Services are created only when a specific forcing function is demonstrated (workload starvation, independent scaling, team ownership). See Service Boundaries → Extraction Forcing Functions. :::