Firestore Offline Writes
The server-side database resolves the conflict using the last-write-it-receives-wins method.
Firestore Facts
- The default cache size is 100 MB for Swift SDK.
- The SDK kicks out data when the cache size exceeds the limit based on the LRU eviction policy.
- Write callbacks do not get called until the server confirms the operations.
- There is no index for the offline cache.
Main Story
Firestore mobile SDKs use offline cache by default. Even when the device is offline, the app can query to the local copy of the database. This feature is the defining characteristic of Firestore as a mobile-first database.
Offline reads are processed as many of you expect. The SDK issues query against the small local database instead of the canonical database sitting on the cloud. Note that the offline queries do not have to be identical to the ones the app has issued while online.
The SDK makes offline writes to the local cache. The write operations are queued up locally and sent to the cloud database when it is online. When only one device updated a specific document, the cloud database would replay the operations as they occurred. When multiple devices have updated the same document, the server-side database resolves the conflict using the last-write-it-receives-wins.
The last-write-it-receives-wins strategy does not consider when the conflicting writes occurred on the local devices. This strategy is easy to reason about compared to the conflict resolution strategies employed by other multi-leader databases (such as last-write-wins). It is the unique topology of Firestore that enables the last-write-it-receives-wins method. Firestore is a multi-leader database in the sense that database clients can write to any of the nodes. However, the database in the cloud is the authoritative node, and the other nodes on the ground are second-class citizens. This single-leader-like topology keeps the conflict resolution simple.