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.
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.
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.
Yeah, I glossed over a bunch of the things we tried near the bottom of the "In-Memory Database" section. One of the things was CRDTs.
We did a few days of CRDT investigation along with the other techniques and decided the juice wasn't worth the squeeze when we found a simpler solution to our problem.
That being said, we've actually retained a CRDT-like implementation in our codebase and have been considering moving shapes (which have a slightly different set of tradeoffs) to that model.
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.
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.
In this case it's just a (transaction/commit) log. Very common in distributed systems, databases, and filesystems.
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.
Oh, this is interesting. What sort of project did you use it for?
I’m surprised there was no mention of operational CRDT’s, or CRDT’s generally.
Yeah, I glossed over a bunch of the things we tried near the bottom of the "In-Memory Database" section. One of the things was CRDTs.
We did a few days of CRDT investigation along with the other techniques and decided the juice wasn't worth the squeeze when we found a simpler solution to our problem.
That being said, we've actually retained a CRDT-like implementation in our codebase and have been considering moving shapes (which have a slightly different set of tradeoffs) to that model.
There's no need for CRDTs here because there is always a central authority.