3 Replicated data

Each participating site can have its own database containing a replica of the data it needs. The database is embedded in the process, persisted on local storage, and cached in memory. Applications therefore read and update a local database instead of sending every request to a central server.

Updates to a database are represented as operations. Sites exchange these operations to bring their replicas into agreement. The data is divided into topics called working sets, so a site can subscribe to the parts relevant to its users instead of holding the entire distributed data set.

Applications use their local database

The application-facing path is local, high-bandwidth, and low-latency. A network outage does not turn an ordinary field access into a failed remote procedure call. The application can continue to view and edit its local state while replication proceeds independently whenever connections permit.

This separation is a major source of simplicity. Applications manipulate their model; the database system is responsible for persistence and synchronisation. Multi-user software can consequently feel like single-user software even when its users are separated by slow or unreliable networks.