4 ms·
>LiteFS has a single-writer multi-reader architecture; it's the same strategy you'd use to scale out Postgres I'm curious about how such a strategy deals with
by xmonkee 4y ago
>LiteFS has a single-writer multi-reader architecture; it's the same strategy you'd use to scale out Postgres
I'm curious about how such a strategy deals with applications that update a value and then read the updated value back to the user, since there might be a replication delay between the write (that goes to the master) and the read (that comes from the closest replica). Do you make optimistic updates on the client or do you club (write-then-read) operations into a transaction?
- kasey_junk 4y agoThis is an application (and frequently data type) dependent decision. Some data is safe to return on acceptance others need to wait for acknowledged writes. The most naive solution is to just make all writes slow but acknowledged.
- benbjohnson 4y agoLiteFS author here. It depends on the application. You can check the replication position on the replicas and simply wait until the replica catches up. That requires maintaining that position on the client though. An easier approach that works for a lot of apps is to simply have the client read from the primary for a period of time (e.g. 5 seconds) after they issue a write. That's easy to implement with a cookie and it's typically "good enough" consistency for many read-heavy applications.