Hi,
I've been building ZamSync, a Rust sync engine for clinic networks in low-connectivity environments (2G, satellite, power outages mid-transfer). I think the CHT sync layer is the closest public analog to what it addresses, so worth raising here.
CouchDB replication is designed for well-connected environments. When a TCP connection drops mid-sync, it restarts from the last checkpoint, which is expensive on 23 kbps links. ZamSync uses an append-only WAL with Hybrid Logical Clocks and Version Vectors: each node tracks exactly which events every peer has seen and sends only the delta on reconnect. No duplicates, no full restarts, crash-safe (WAL survives power cuts).
Static binary, under 10 MB RAM on a Raspberry Pi 3, no runtime dependencies.
Concrete question: when CHT field devices reconnect after hours or days of disconnection, does CouchDB replication handle the sync cleanly in practice, or do you see timeout and corruption issues that require manual intervention? I'm curious what the actual failure modes look like at scale.
GitHub: https://github.com/Etoile-Bleu/ZamSync
Deep dive: https://dev.to/etoile_bleu/-i-built-a-sync-engine-for-clinics-that-run-on-2g-and-lose-power-mid-transfer-here-is-why-and-18od
Hi,
I've been building ZamSync, a Rust sync engine for clinic networks in low-connectivity environments (2G, satellite, power outages mid-transfer). I think the CHT sync layer is the closest public analog to what it addresses, so worth raising here.
CouchDB replication is designed for well-connected environments. When a TCP connection drops mid-sync, it restarts from the last checkpoint, which is expensive on 23 kbps links. ZamSync uses an append-only WAL with Hybrid Logical Clocks and Version Vectors: each node tracks exactly which events every peer has seen and sends only the delta on reconnect. No duplicates, no full restarts, crash-safe (WAL survives power cuts).
Static binary, under 10 MB RAM on a Raspberry Pi 3, no runtime dependencies.
Concrete question: when CHT field devices reconnect after hours or days of disconnection, does CouchDB replication handle the sync cleanly in practice, or do you see timeout and corruption issues that require manual intervention? I'm curious what the actual failure modes look like at scale.
GitHub: https://github.com/Etoile-Bleu/ZamSync
Deep dive: https://dev.to/etoile_bleu/-i-built-a-sync-engine-for-clinics-that-run-on-2g-and-lose-power-mid-transfer-here-is-why-and-18od