Sync / Editing server data
When to use it, and who owns what
| You have | Use | Who owns the fact |
|---|---|---|
| Rows a server holds, edited online, where losing the cache loses nothing | a Remote mutation | the server; the client's optimistic layer goes when the request settles |
| Shared state small enough for every replica to hold whole | a Sync slice | the journal; every replica keeps the document |
| Rows too many to replicate, edited offline, and the edits must converge | this pattern | the journal owns the edits; the table is derived from them |
In this pattern:
- The journal owns the edits. Each is a durable Message, committed in one
order, stamped with the sequence it committed at (
at) and who committed it (by). - The table is the journal's read model. Only the journal writes it: each
committed edit, applied with its sequence. Each row carries the highest
sequence applied to it, its
revision. The table is not a second owner; it can be rebuilt from the seed and the log. - Remote caches the table's rows, as it caches any server-owned fact.
- The replicated slice holds only what the table lacks: edits not yet applied, or applied but not yet read back. Usually nothing.