In a previous post about LiteFS [1], the creator Ben commented on how clients could maintain a monotonically consistent view of the database [2] even in the pre

In a previous post about LiteFS [1], the creator Ben commented on how clients could maintain a monotonically consistent view of the database [2] even in the presence of replication lag and updates made by the client. I think this is a pretty good (TM) strategy that should work well for a majority of applications. > > To improve latency, we're aiming at a scale-out model that works similarly to Fly Postgres. That's to say: writes get forwarded to the primary and all read requests get served from their local copies. > How can you ensure that a client that just performed a forwarded write will be able to read that back on their local replica on subsequent reads? > LiteFS provides a transaction ID that applications can use to determine replication lag. If the replica is behind the TXID, it can either wait or it can forward to the primary to ensure consistency. [1]: https://news.ycombinator.com/item?id=32925734#32928974 https://news.ycombinator.com/item?id=32925734#32928974 [2]: I think this is a reasonable statement, but may not be industry standard terminology.