Allow Stale Reads

Eventual Consistency

Each client can be put into “allow stale” mode, which enables “eventually consistent reads”. Calling a “with allow stale” method will return a new copy of the client that allows stale reads, without modifying the original client. By default, all reads in StatelyDB are strongly consistent—if you write some data and read it back after (even from another client), you’ll see your update. “allow stale” says that you accept a bit of staleness in reads. Many applications are actually quite tolerant of this and don’t need to get the exact up to date view of data. The advantage of enabling this setting is a potential improvement in both latency and cost - it’s cheaper and easier to read without having to make sure the write has already reached consensus within a database cluster.

This isn’t available within a transaction because transactions are always consistent—that’s the whole point of them!

For example, imagine you have stored some global settings in an Item, and your clients occasionally poll to refresh their view of those settings. Settings occasionally get updated by an administrative user. It doesn’t really matter that each client gets the exact up to date version of the setting versus one that could be a little out of date, because the change is happening infrequently, and because you’re polling the value you already accept that the client’s view of the setting could be a bit out of date. (P.S. use SyncList if you want to do this sort of polling).

Go

item, err := client.WithAllowStale(true).Get(ctx, keyPath)

Ruby

item = client.with_allow_stale(true).get(key_path)

Python

item = await client.with_allow_stale(true).get(Movie, key_path)

TypeScript

item = await client.withAllowStale(true).get('Movie', keyPath)