All notable changes to the sync module are documented in this file.
The sync module is responsible for deterministic convergence between peers in a local-first system.
It orchestrates operations coming from WAL, network, and local state to ensure eventual consistency under failure.
-
Core
SyncEngineorchestrator -
Operationabstraction:- Logical representation of changes
- Independent from transport format
-
Basic
SyncPlanner:- Detect missing operations
- Prepare outbound operations
-
SyncApplier:- Apply incoming operations
- Basic validation
-
PendingQueue:- Track outgoing and incoming operations
- Operations can be applied in a consistent order
- Basic convergence between two peers
- Integration with WAL for replay
- No dependency on filesystem internals
- No direct network handling
- Pure orchestration logic
- Idempotent operation application
- Safer handling of duplicate operations
- More consistent sync state tracking
- Edge cases where operations could be applied twice incorrectly
- Missing validation checks for malformed operations
-
Reconcilercomponent:- Detect divergence between peers
- Apply basic resolution strategy (last-write-wins)
-
Version tracking for operations
-
Basic state comparison helpers
- Deterministic behavior across peers
- Reduced inconsistency during concurrent updates
- Full WAL-driven recovery integration
- Resume sync from last known sequence
- Replay-safe operation application
- Faster convergence after restart
- More predictable recovery flow
- Incorrect behavior when replaying partial operation sets
- State inconsistencies after crash recovery
-
Clear separation between:
- Planning
- Application
- Transport interaction
-
Sync request/response patterns (abstract)
- Handling of out-of-order operations
- Better tolerance to network delays
- Duplicate detection mechanisms
- Retry-aware sync logic
- Handling of partially applied states
- Stability under intermittent connectivity
- Reduced divergence windows between peers
- Batch processing of operations
- Queue optimization
- Reduced overhead in sync cycles
- Faster processing of large operation sets
- Namespace stabilization (
softadastra::sync) - Public API cleanup
- Clear module boundaries
-
Decoupling from application-specific assumptions
-
Prepared for reuse in:
- Softadastra Sync OS
- SDK
- Embedded systems
- Multi-peer synchronization
- CRDT-based conflict resolution
- Vector clocks / causal ordering
- Partial sync (delta-based)
- Compression and streaming
- End-to-end encryption support
The sync engine is the brain of the system.
The goal is not to be fast first. The goal is to be correct under all conditions.
- Never assume network order
- Always support replay
- Always be idempotent
- Always converge
The sync module ensures:
- Eventual consistency
- Deterministic convergence
- Recovery after failure
- Correctness under unreliable networks
It is the core intelligence of Softadastra.