Build1 publisher3 min readPublished
One question about concurrent edits separates days of caching work from a replica build
A dev.to post pulls three different builds out of the phrase "offline mode", each with its own bill. The test for which one you owe is whether two disconnected devices can change the same row.
The Engineer · Build desk
What happened
- A dev.to post argues that "offline mode" names three different builds, and that working out which one a stakeholder means is the most useful thing an engineer can do in the first hour.
- Level 2 lets the user capture photos, readings and job sheets offline and queues them for upload, with data flowing one way so nothing on the server contradicts the queue.
- The post's sorting question is whether two people can change the same record while both are offline.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A no to the concurrency question keeps conflict rules out of scope entirely; a yes puts them in writing before anyone gives an estimate, because the rules are then part of the build.
- cost Most of the budget sits between level 1 and level 3, and the post says almost nobody states which one they mean, so the scoping error is paid by whoever quoted the number.
- exposure Once work is captured on the device, a lost phone is a copy of company data, and for regulated data the wipe path and local retention rule become week-one design inputs.
- constraint The worst realistic outage caps how much data has to sit on the device. That makes the working set a product decision.
Level 2 is cheap for a structural reason. Data flows one way, so nothing on the server contradicts the queue and there is nothing to reconcile [6]. Level 3 pays for convergence instead: conflict resolution, partial sync, schema migrations on devices that have not phoned home in a month, and a class of bug that only appears when two clocks and two copies disagree [9].
The split can run inside one product. In the author's own app, LectureNotes AI, recording the lecture must never depend on connectivity, while transcribing and summarizing it is heavy work that can wait for a better connection [8].
The request arrived three weeks before launch, in the same tone as a request for a dark theme, and the author agreed because storing data on a device is not hard [1]. "Offline is not a feature you bolt on. It is a decision about where the truth lives, and it is far cheaper to make in week one than in week twenty," the post's author wrote [2].
The sorting question is one line: "Can two people change the same record while both are offline?" [11]. If every user only creates their own records, or each record belongs to one person for the duration of a job, conflict resolution never enters scope and the build stays at level 2 [12]. Read that condition strictly. Exclusive ownership has to hold for the entire time the device is dark, so an office user editing the same row at noon puts the work at level 3 no matter how the field app behaves.
The assertion that most field software wants level 2 and only level 2 [7] is a claim about one practitioner's client list, and the post does not give counts. It transfers to your system only if record ownership is exclusive for the length of an outage. Same caution on the claim that a surprising share of "we need offline mode" requests are fully satisfied at level 1 [5]. The level-1 symptoms are specific enough to check against a brief: cached screens render, a half-finished form survives, and the app recovers on its own when signal returns [4]. In my view that is the right first scope whenever nobody can answer the concurrency question in writing, because being wrong there costs a few days of caching.
The questions get front-loaded [21]. The outage question wants the worst case, because ninety seconds in a lift is a retry problem and a full shift underground is an architecture [13]. The working set is usually narrow, and defining it is a product conversation [14]. On device loss the post is blunt: "An offline app is a copy of company data in a coat pocket" [15].
Conflict rules go per record type [17]. Last write wins is cheap and silently destroys work, which the post allows for a status flag and not for anything a person spent ten minutes typing [18]. Ownership per field gives the office the customer address and the field the job outcome, and the post says it "costs a conversation rather than a merge engine" [19]. The third rule records events instead of states: readings taken, parts used, notes added [20].
Then there is the warm-up. Data pulled, assets cached, queue empty, or the user walks away with a copy that is confidently wrong all day. The apps that work in the field show when the device last synchronized and whether it is safe to go dark [16].
What to watch
- Any measured count behind "a surprising share" of requests satisfied at level 1 would move that from one practitioner's client list to a defensible default.
- A worked example of per-field ownership colliding, where the office and the field both need the same field, would test the claim that it avoids a merge engine.
- Regulated-data projects where the wipe path and local retention rule actually changed the design would confirm the week-one placement.