This is old and out-dated. Please see https://doc.replicache.dev/strategies/overview instead.

🌁 Overview

The Global Version Strategy is the same as the The Last-Modified Strategy except it uses a monotonic clock instead of a non-monotonic/wall clock.

It fixes the correctness issues with the Last-Modified Strategy, but at the cost of significant concurrency limits — write throughput to the server is limited to the concurrency of the monotonic clock implementation.

👩🏻‍🏫 How it Works

Setup

1. Setup database as-per The Last-Modified Strategy. Instead of a LastModified field, add a Version field.
2. Add a field to your database somewhere that stores a single integer. Call this LastVersion. Implement a NextVersion() function that increments and returns this counter. (Note: Some databases have a first-class feature for this).
3. Call NextVersion() instead of Now() whenever updating the Version field of an entity.

On Pull

• Same as The Last-Modified Strategy.

😓 Challenges

• Although easy and correct, the The Global Version Strategy has poor concurrency characteristics. NextVersion() must be serialized which makes it a global lock across all writes. Worse, the lock must be held at minimum across an entire mutation, since we do not want any possibility of versions from mutations getting written out of order. This severely limits possible concurrency of your backend: if NextVersion takes 10ms then the maximum number of calls to replicache-push per second is 100.
• All challenges except correctness from The Last-Modified Strategy are shared by this strategy.

🌈 Variations

The same variations available to The Last-Modified Strategy apply here.

✍🏽 Examples

The integration guide sample app uses the Global Version Strategy. See: https://doc.replicache.dev/guide/remote-database.