Read one moment, even while writes continue

A run that makes a decision usually reads several records first. If the run is also writing, those reads can land on either side of a write, so the decision is built from an older value and a newer one at the same time. Nothing errors. Each value is valid on its own, and the combination is a state the system never actually held.

Pin a read point

Choose the moment, then read every input as of that moment. A read point is the version or timestamp that all the reads share, so the set of values belongs together even while writes continue in the background.

Check the snapshot against the writes it depends on

A snapshot can be consistent and still be too old. If a write the decision depends on landed after the read point, the snapshot predates the fact. The answer is to take a new snapshot rather than to patch one value in from a newer read, because patching brings back exactly the mixture the snapshot was chosen to remove.

def read_consistent(store, keys, read_point):
    snapshot = {k: store.get(k, at=read_point) for k in keys}
    if store.last_write() > read_point:
        return None
    return snapshot

Retry the whole read

When the snapshot is too old, or a value is missing from it, discard it and read again from a fresh point. Retrying a single field is what produces the inconsistency in the first place.

Where the cost is not worth it

A read whose inputs nothing writes during the decision does not need a snapshot at all. Spend it where a later step depends on the values having come from one moment.