A field service app must work offline. Engineers book parts from a shared inventory. What is the design problem?
Show the full answer Hide the answer
What the interviewer is testing
Whether you recognise which parts of a domain can tolerate offline operation and which cannot.
The problem
Inventory has a global invariant: a part cannot be allocated twice. Offline devices cannot see each other's allocations, so two engineers offline in different locations can both book the last part.
There is no conflict resolution that repairs this, because the conflict is not about data — it is about a physical object that only one of them can have. Convergence is not correctness.
The design
Split the domain by what tolerates offline operation:
| Operation | Offline? |
|---|---|
| View job details, history, manuals | Yes — read-only replicated data |
| Record work performed, notes, photos, signatures | Yes — append-only, no shared invariant |
| Record parts used from van stock | Yes — the engineer physically holds them |
| Book parts from shared warehouse stock | No — global invariant |
Van stock is the key insight. Allocating parts to an engineer's vehicle in advance, while connected, converts a shared resource into a locally owned one. The engineer then consumes from their own stock offline with no contention, and reconciles later. This is the design that makes the whole system work, and it is a domain change rather than a technical one.
For genuine shared allocation, use reservations while connected, with a time-bounded hold that expires — so an engineer reserves before travelling, and an abandoned reservation returns to the pool.
Where an offline request for shared stock is unavoidable, queue it as a request rather than an allocation, and confirm on reconnection. The user interface must show it as pending, not confirmed — showing an optimistic confirmation that may be revoked is worse than showing the truth.
What a strong answer adds
Naming the general rule: offline-first works for data the user owns and fails for contended resources. The architectural move is usually to partition ownership so that what looks contended becomes locally owned — which is the same insight as single-writer partitioning in distributed systems.
Common weak answers
Last-write-wins on the inventory count. CRDTs, which converge and cannot enforce the invariant.