export declare const architectureContent = "# LiveStore Architecture: Local-First Data Management\n\nLiveStore implements distributed systems principles from Martin Kleppmann's research on local-first software, ensuring data consistency, availability, and partition tolerance in collaborative applications.\n\n## Core Architectural Principles\n\n### 1. Local-First Data Storage\n- **Immediate Response**: All operations execute against local SQLite database first\n- **Offline Capability**: Full application functionality without network connectivity\n- **Data Ownership**: Users maintain complete control over their data\n- **Performance**: Sub-millisecond query responses from local storage\n\n### 2. Event Sourcing & CRDT-Inspired Conflict Resolution\n- **Immutable Event Log**: All changes recorded as immutable events\n- **Deterministic Replay**: State reconstruction from event sequence\n- **Conflict-Free Operations**: Events designed for commutative application\n- **Causal Ordering**: Lamport timestamps ensure causally consistent ordering\n\n### 3. Eventually Consistent Synchronization\n- **Asynchronous Replication**: Events sync when network available\n- **Convergence Guarantee**: All replicas converge to same state\n- **Conflict Resolution**: Last-write-wins with semantic merging strategies\n- **Incremental Sync**: Only transmit events since last synchronization\n\n## System Components\n\n### \uD83D\uDDC4\uFE0F State Layer (SQLite + Materializers)\n```typescript\n// Materialized views from event log\nconst materializers = State.SQLite.materializers(events, {\n  'TodoCreated': ({ id, text, createdAt }) => \n    tables.todos.insert({ id, text, completed: false, createdAt }),\n  'TodoCompleted': ({ id }) => \n    tables.todos.update({ completed: true }).where({ id })\n})\n```\n\n**Responsibilities:**\n- Maintain denormalized query-optimized state\n- Apply events to update materialized views\n- Support efficient reactive queries\n- Handle schema migrations\n\n### \uD83D\uDCDD Event System (Append-Only Log)\n```typescript\nconst events = {\n  todoCompleted: Events.synced({\n    name: 'v1.TodoCompleted',\n    schema: Schema.Struct({ \n      id: Schema.String,\n      completedAt: Schema.Date // For conflict resolution\n    })\n  })\n}\n```\n\n**Characteristics:**\n- Immutable event log (append-only)\n- Cryptographically signed events for integrity\n- Causal dependencies tracked via vector clocks\n- Schema versioning for backward compatibility\n\n### \uD83D\uDD04 Synchronization Engine\n```typescript\n// Conflict resolution during sync\nconst mergeResult = SyncState.merge({\n  syncState: currentState,\n  payload: incomingEvents,\n  isEqualEvent: (a, b) => a.id === b.id && a.type === b.type\n})\n```\n\n**Merge Strategies:**\n- **Advance**: New events extend current state\n- **Rebase**: Rollback conflicting events, apply remote, replay local\n- **Reject**: Ignore events that violate invariants\n\n### \uD83C\uDF10 Network Layer & Adapters\n```typescript\n// Platform-specific sync adapters\nexport const WebAdapter = {\n  storage: OPFSSQLiteStorage, // Origin Private File System\n  transport: WebSocketSync,\n  worker: SharedWorker        // Cross-tab synchronization\n}\n```\n\n**Adapter Implementations:**\n- **Web**: OPFS storage, SharedWorker coordination, WebSocket sync\n- **Node**: File system storage, cluster coordination, HTTP/WebSocket\n- **Mobile**: Native SQLite, background sync, push notifications\n\n## Distributed Systems Properties\n\n### CAP Theorem Considerations\n- **Consistency**: Eventually consistent (not strongly consistent)\n- **Availability**: Always available for reads/writes (local-first)\n- **Partition Tolerance**: Continues operation during network partitions\n\n*Trade-off: Chooses Availability + Partition Tolerance over strong Consistency*\n\n### ACID Properties (Local Transactions)\n- **Atomicity**: Event application is atomic within SQLite transaction\n- **Consistency**: Materializers maintain data integrity constraints\n- **Isolation**: Concurrent operations isolated via SQLite WAL mode\n- **Durability**: Events persisted to disk before acknowledgment\n\n### Conflict Resolution Strategies\n\n1. **Semantic Conflict Resolution**\n   - Application-specific merge logic\n   - E.g., text editing uses operational transforms\n\n2. **Last-Write-Wins (LWW)**\n   - Timestamps determine winner\n   - Simple but can lose data\n\n3. **Multi-Value Registers**\n   - Preserve all conflicting values\n   - User or application resolves\n\n4. **Commutative Operations**\n   - Operations designed to commute\n   - E.g., increment/decrement counters\n\n## Performance & Scalability\n\n### Query Performance\n- **Reactive Queries**: Automatically update UI on data changes\n- **Indexed Access**: SQLite B-tree indexes for fast lookups\n- **Prepared Statements**: Query compilation cached for reuse\n- **Batch Operations**: Multiple events applied in single transaction\n\n### Memory Management\n- **Incremental Loading**: Large datasets loaded on-demand\n- **Query Result Caching**: Expensive query results cached\n- **Event Log Compaction**: Periodic snapshotting and log truncation\n- **Connection Pooling**: Database connections reused across operations\n\n### Network Optimization\n- **Delta Synchronization**: Only sync events since last checkpoint\n- **Compression**: Event payloads compressed for network transfer\n- **Batching**: Multiple events transmitted in single round-trip\n- **Exponential Backoff**: Retry failed sync with increasing delays\n\n## Security Model\n\n### Data Integrity\n- **Event Signatures**: Cryptographic signatures prevent tampering\n- **Merkle Trees**: Efficient verification of event log integrity\n- **Schema Validation**: All events validated against defined schemas\n\n### Access Control\n- **Client-Side Authorization**: Fine-grained permissions in local database\n- **Sync Filtering**: Server filters events based on user permissions\n- **Encryption**: End-to-end encryption for sensitive data\n\n## Observability\n\n### Distributed Tracing\n- **Event Causality**: Trace event propagation across replicas\n- **Sync Performance**: Monitor replication lag and throughput\n- **Conflict Metrics**: Track merge conflicts and resolution strategies\n\n### Health Monitoring\n- **Storage Usage**: Local database size and growth rate\n- **Network Health**: Connection quality and sync success rates\n- **Error Tracking**: Failed operations and their root causes\n\nThis architecture enables applications that work seamlessly offline, sync reliably when online, and provide immediate feedback to users while maintaining data consistency across all replicas.";
//# sourceMappingURL=architecture.d.ts.map