We are often asked to "add offline support" to an application that is well into development. It rarely goes well.
Why retrofitting fails
Offline capability is not a synchronisation layer bolted onto an application that assumes a server is always reachable. It is a set of decisions about identity, conflict and ordering that reach all the way into the data model.
The three questions to answer first
- Who generates identifiers? If the server allocates primary keys, an offline client cannot create records. Use client-generated UUIDs.
- What happens when two people edit the same record? Last-write-wins is a decision, not a default. Make it deliberately.
- What must never be queued? Some operations — a payment, a clinical alert — must fail loudly rather than sit in a queue.
A worked example
On a recent clinical records project, we made every record client-generated and append-only. A patient record is a sequence of observations, not a mutable row. Conflicts stop being conflicts because nothing is ever overwritten.