I find it fascinating when different people independently arrive at the same architecture when working on a hard problem like this. In my company we built our offline-first apps with PowerSync, which has the same idea of optimistic local changes while waiting for the central server to acknowledge the definitive changes. In PowerSync's case, the sync engine reads Postgres replication logs directly.
tyleo•1h ago
Yeah, I'm surprised this pattern doesn't have a more general name.
I've also used it to synchronize content for local multi-window editing applications: each window is its own process but routes through one "coordination" process to ensure consistent ordering.
Easily solves some cross-process concurrency issues.
Rohansi•10m ago
In this case it's just a (transaction/commit) log. Very common in distributed systems, databases, and filesystems.
wpietri•1h ago
For those interested in a keep-everything-hot approach like this, it's worth checking out the 25-year-old library Prevayler. Full ACID guarantees, and radically faster than a database. I happily used it for a project forever ago and was disappointed to see it so thoroughly ignored.
tyleo•1h ago
Oh, this is interesting. What sort of project did you use it for?
davidanekstein•12m ago
I’m surprised there was no mention of operational CRDT’s, or CRDT’s generally.
Rohansi•5m ago
There's no need for CRDTs here because there is always a central authority.
giovannibonetti•1h ago
tyleo•1h ago
I've also used it to synchronize content for local multi-window editing applications: each window is its own process but routes through one "coordination" process to ensure consistent ordering.
Easily solves some cross-process concurrency issues.
Rohansi•10m ago