Your backend can recover from a failed request; a mobile client may lose connectivity halfway through one. On a small budget, I would spend less on screens and more on deciding what happens to an unfinished write. That sounds like overengineering until a user taps Save twice on a train and your service creates two records. The proper version starts with a narrow, testable write contract.
A cheap mobile client becomes expensive at the first uncertain write
Pick one consequential action before choosing a mobile stack: for example, a user edits an order quantity and taps Save. The request might reach your server even though the response never reaches the phone. Retrying is necessary if the user’s change is to survive, but an ordinary repeated POST may apply it twice. That uncertainty, rather than rendering the edit screen, is the first problem a backend developer should budget for.
Compare two named options. Direct POST on tap wins when an action is disposable, the user must be online, and a failed attempt can safely be repeated by hand; it costs little client code but shifts ambiguity to the user. A durable command queue wins when a confirmed edit must survive an app restart or a connection change; it costs local persistence, retry logic, and server-side deduplication. Neither option is inherently “proper.” The second earns its cost only when losing or duplicating that particular action would matter.
For the order edit, I would fund the durable queue and cut a less consequential feature to pay for it. I would not buy a cheap client implementation that promises offline support without specifying retry identity, because “stores requests locally” says nothing about what the server does when the same request arrives again. A buy-versus-build comparison (Build Mobile In-House or Buy A Cheap App That Holds Up) can pressure-test the price, but its sticker price cannot settle who owns an ambiguous write after launch.
Make a small contract before building the queue. Give each user action a stable idempotency key, keep it unchanged across retries, and scope it to the authenticated account. If the same key arrives with the same payload, return the original outcome; if it arrives with a different payload, return HTTP 409 Conflict. Record the decision in OpenAPI 3.1, with the payload defined using JSON Schema 2020-12, because a mobile developer should not have to infer retry behavior from a successful-response example. RFC 9457 problem details can give the conflict a machine-readable response without inventing a private error envelope.
The budget boundary is specific: queue this one write, not every interaction. A search query can be retried from the current screen because stale search results have little value; an acknowledged order edit needs a durable identity because the user may reasonably assume it was saved. A two-engineer-day allowance for the first contract and failure drill is a planning estimate to challenge against your codebase, not a claim that offline support always takes two days.
Server idempotency should precede client retry logic
A mobile retry button is easy to add and hard to trust without a server guarantee. Start with a server-side table whose uniqueness constraint arbitrates competing attempts; an in-memory set cannot protect a write across process restarts. The following Python example runs with the standard library and illustrates the decision, rather than a production endpoint. It requires SQLite 3.24.0 or later for ON CONFLICT DO NOTHING:
import hashlib
import sqlite3
db = sqlite3.connect(":memory:")
db.execute("CREATE TABLE commands (key TEXT PRIMARY KEY, digest TEXT NOT NULL)")
def accept(key, body):
digest = hashlib.sha256(body.encode()).hexdigest()
with db:
written = db.execute(
"INSERT INTO commands VALUES (?, ?) ON CONFLICT(key) DO NOTHING",
(key, digest)).rowcount
stored = db.execute("SELECT digest FROM commands WHERE key = ?", (key,)).fetchone()[0]
return "created" if written else ("replayed" if stored == digest else "conflict")
print(accept("offline-42", '{"qty":1}'))
print(accept("offline-42", '{"qty":1}'))
print(accept("offline-42", '{"qty":2}'))
The three calls produce created, replayed, and conflict; those are the example’s deterministic results, not measured production reliability. In a real service, persist the command record and the business change in one transaction. Otherwise, a crash between “key accepted” and “order updated” could make the next attempt look like a replay even though the work never happened. Store the original response or a reference to the resulting resource, because returning a fresh success assembled from current state can misrepresent an earlier write.
Also decide what the key identifies. A random identifier generated on every HTTP attempt defeats deduplication because each retry looks new. Generate it when the user action enters the local queue, then send it as an Idempotency-Key header on each attempt. Treat a body mismatch as a conflict rather than silently accepting it, because reusing a key for a changed edit would hide a client bug. Scope lookup by account or tenant, since a global key space can cause unrelated users’ requests to interfere.
Expiration is a product decision tied to the longest plausible offline period. A proposed seven-day retention window is a value to tune after observing how long queued edits actually wait; deleting keys sooner than clients may retry restores the duplication risk. Publish that window alongside the API contract so the client can stop claiming an old command is safe to resend. HTTP semantics in RFC 9110 help distinguish conflicts from transient server failures, but your API still has to say which failures the client should retry.
Background execution cannot be your delivery guarantee
Once the endpoint is safe to retry, the phone still needs a plan for when to try. Android WorkManager can run persistent work after an app restart, and NetworkType.CONNECTED avoids attempting a transfer without a network. Use a unique work name for the queue drain; choose ExistingWorkPolicy.KEEP when a drain is already scheduled, because replacing it after every edit can keep postponing work. Exponential backoff limits repeated attempts during an outage, though the exact delay should be tuned against the cost of late delivery.
On iOS, BGTaskScheduler can request background opportunities, but the system chooses when work runs; it is not a timer that promises an immediate upload. Design both clients to drain the queue when the app is opened as well as when background execution is granted. Show a pending state until the server confirms the edit, because a locally stored command is not the same thing as a completed server write. If users can modify the same order elsewhere, include a server version or ETag and use If-Match, so a delayed mobile edit does not silently overwrite newer data.
This is where a backend developer’s usual request model needs adjustment. A five-second HTTP timeout can be a reasonable setting to test, but it says only when one attempt stops waiting; it does not say whether the server committed the change. Separate attempt state from command state in the client. “Timed out” describes an attempt. “Pending confirmation,” “confirmed,” and “needs user resolution” describe the command. That distinction makes the interface honest when connectivity is unreliable.
Protect credentials without turning this narrow project into a general security-platform build. Use OAuth 2.0 authorization code flow with PKCE for sign-in, and keep tokens in iOS Keychain or Android Keystore-backed storage rather than in the queued payload. Queue the business input and command identifier, not a snapshot of an access token, because tokens can expire while a phone is offline. Encrypting a local database may be warranted for sensitive stored content, but it does not replace server authorization on a replayed request.
One failure drill buys more confidence than another polished screen
A low-cost release can still have a proper acceptance test. Run the edit on a device, sever connectivity after the request leaves, kill and reopen the app, restore connectivity, and inspect the server result. Then send the same key with a changed payload and check that it fails visibly. Use mitmproxy to interrupt traffic during development and Maestro to repeat the user path; use Android Studio Profiler or Xcode Instruments if the queue drains slowly or consumes unexpected resources. These tools answer different questions, so installing all of them without a written failure scenario would waste the budget.
For an initial release gate, I would require zero duplicate business changes across 20 forced-retry trials. That is a proposed acceptance threshold, not a statistical guarantee: it is cheap enough to run manually and strict enough to expose a missing uniqueness constraint. Measure the time from reconnection to confirmation as a p95 latency metric in subsequent trials, rather than reporting only average request duration, because a handful of stranded commands are precisely what the drill is meant to find. Add an OpenTelemetry trace attribute for the command identifier on the server, but keep that identifier out of logs if it contains user data.
Firebase Crashlytics or Sentry can reveal client crashes, while a server metric such as pending-command age reveals work that never completes; crash-free sessions alone cannot prove delivery. Ship the drill build through TestFlight and Google Play internal testing before a wider release, because installed builds encounter lifecycle behavior that a developer’s foreground session may miss. Faster-delivery advice (Mobile App Development Insights for Faster Delivery) is useful only if “faster” includes discovering a stuck command before users do.
Do not build a broad synchronization framework for this first workflow, because its conflict policies and migration surface would consume money before you have evidence of a second offline need. Keep the command table, API contract, and release drill small enough that another developer can explain what happens after a timeout. If the drill fails, fix that path before adding background scheduling refinements or visual polish.
The first budget decision should be a failure you can reproduce
Tomorrow, take one real write endpoint and reproduce a lost response: let the server commit, then prevent the phone from receiving confirmation. Record what the user sees, what a retry sends, and what the database stores. If you cannot distinguish “saved once” from “possibly saved twice,” allocate the next slice of budget to the write contract—not to another screen.
