Read your own writes, off the primary 0 ▲ boringSQL | Supercharge your SQL & PostgreSQL powers 47 minutes ago · 18 min read3535 words · Tech · hide · 0 comments Your API accepts the change. It returns 201 Created or 200 OK, the system has saved the user's change, and the moment the user clicks, the change disappears from the app, only to resurface seconds later. That's if you are lucky. There's no error. The change simply ceased to exist for a while. In the era of server-side-rendered applications this was a non-issue: either the state was managed as part of a single request, or the user was too slow to outrun the system. The modern application changed that. It fires off the mutation, invalidates the cache, and wakes up the state management, all in parallel and milliseconds after the write. The snappier your frontend feels, the more reliably it outruns your replica. Throw a collaborative product into the mix and it gets worse, because every change sent over a websocket invalidates state on every teammate's open tab and device, and all of them go back to the same endpoints on the same replicas. Some of the common workarounds are: pin reads to… No comments yet. Log in to reply on the Fediverse. Comments will appear here.