Notes App

Make the list a function of the database, not of the save call. Room can expose a query as an observable Flow, so the list screen subscribes once and Room re-emits the whole list on every write - the editor's job ends at the insert, and the list updates itself.

@Query("SELECT * FROM notes WHERE isDeleted = 0 ORDER BY updatedAt DESC")
fun observeNotes(): Flow<List<Note>>

Now the architecture is honest about what's authoritative: the user's edits live in Room and the screen just draws whatever Room currently holds, so the write path has zero network in it. The network becomes a separate, downstream concern - getting what's already saved up to the cloud - which is the next dive. This is the state management shape the rest of the app inherits: one source of truth, the UI derived from it.

One failure mode remains, and it's the subtle one: the worker pushes an op, the server commits it, then the 200 is lost to a dropped connection. The outbox row is still there (we only delete on ack), so the next run re-sends it. Without protection the server now applies the same edit twice.

The fix is the client-generated opId on every outbox row. The server records which opIds it has applied and treats a repeat as a no-op, returning the same ack. So the push is safe to retry any number of times.

override suspend fun doWork(): Result {
  val ops = pendingDao.all()
  if (ops.isEmpty()) return Result.success()
  val acked = try { api.sync(ops.toRequest()).acked } catch (e: IOException) { return Result.retry() }
  pendingDao.deleteByOpIds(acked)          // re-sent ops the server already had come back acked too
  return if (pendingDao.count() == 0) Result.success() else Result.retry()
}

Sync is now durable and idempotent. That one outbox row is doing the work: it exists before the first byte leaves and disappears only after the ack, so an interruption anywhere resolves by re-reading rows instead of trusting that the last run finished. The pattern generalizes - any mobile client pushing local writes upstream wants an at-least-once wire under an idempotent server - but here it carries nothing heavier than text deltas.

For the rare case where dropping the loser is unacceptable, don't make the system guess - surface both. When the server detects a conflict, the client keeps the winning version under the original noteId and writes the losing text as a new note titled "(conflicted copy)". The user sees both side by side and merges by hand.

This is deliberately the simplest thing that loses no data: no per-field merge, no operational transform, no CRDT (a conflict-free replicated data type - the structure a collaborative editor uses to merge concurrent edits without a central authority) - those belong in a collaborative doc editor, not a single-user notes app. You buy that safety with a little clutter, an extra note to reconcile. For most notes a rare dropped edit is survivable and last-write-wins is enough; the conflict copy is worth its clutter only when the text is too precious to lose.

Soft-delete is correct but isDeleted rows accumulate forever - a user who creates and deletes thousands of to-dos grows a table of dead markers that every pull and every query pays for. The fix is to treat the deleted row as a tombstone with a lifetime: keep it long enough to guarantee every device has synced the deletion, then purge it.

Concretely, once the server acks the DELETE op and a TTL window passes (say 30 days, comfortably longer than any device stays offline), a local cleanup pass hard-deletes the tombstone, and the server does the same on its side. The TTL is the safety margin: purge too early and a device that was offline past the window pulls a list missing the note and never learns it was deleted, resurrecting it again. Keep it bounded and the table stays small without risking a zombie.