The user who downloads your app does not care about performance. They don’t care about performance metrics, app response time, average fps nor do they know the difference between network latency, network transfer or packet loss. They don’t care about persistence. They care that it works.

A user should not have to be concerned with network latency

To the average user, performance is a feeling. The feeling of smooth movement and of every action having an immediate result. The feeling of not needing to look up between actions. The feeling of immediacy and resilience. Apple taught this from iOS 1.0, scroll up from the top of a list and the action is registered and acted upon — a smoothness that is so inherent in the experience that people rarely speak of it.

Users expect and demand instant reactivity and eventual consistency

To be more specific — A change made by the user can be accepted into the system (written to a database) instantly and yet persisted to the backing data store (via an internal API) asynchronously from the user attention. Perform an action, see a result. Any information that has the possibility of being rejected by the backend should be first rejected by the app.

Download a set of configuration options that define what requirements the data architecture demands. The client can then apply those options to incoming data before it is accepted into the internal persistence queue. Once accepted into the queue, the app will separately be responsible for persisting the addition or change at some point soon.

The notion of at some point soon is so powerful that post-ACID era databases are typically implemented using the notion of eventual consistency which is simply implemented using internal queues to accept data and persist it when convenient.

Implement an eventual consistency queue and remove all of the spinners.