One Record, Two Editors: Avoiding Silent Data Loss
Define how shared business records behave when two people edit at once. Use a two-editor rehearsal to reveal stale saves and agree on a recovery path.
Updated
A shared business application should not silently replace someone else's saved work when a second person submits an older version of the same record. Define a server-side freshness check and a usable recovery path before calling multi-user editing complete.
This technical design note uses a hypothetical two-editor rehearsal to make that requirement concrete. It is for product owners and operations leaders who need to agree on behaviour, not choose a particular database or turn every form into a collaborative document editor.
Key takeaways
- Two individually correct forms can still produce an incorrect shared record.
- Check the version at the point of writing, not only when the screen opens.
- A rejected stale save should preserve the person's proposed changes and explain the next choice.
- Different fields are not automatically safe to merge: business relationships can connect them.
- Test the conflict through every supported write route, including imports and integrations.
Rehearse the collision before discussing the technology
Imagine a fictional equipment-booking application. A coordinator and a dispatcher open the same reservation. Both see the same starting record: the machine is allocated for Tuesday morning, and delivery is to the north entrance.
The coordinator changes the booking to Wednesday and saves. The dispatcher, still looking at Tuesday's version, changes the entrance to the loading bay and saves a form containing the whole record. Without an agreed conflict rule, that second save might restore Tuesday while correctly updating the entrance.
Nobody deliberately undid the date change. Each person completed a reasonable task. The failure sits in the application's treatment of an old representation as though it were the current record.
Use this sequence as an acceptance exercise, not a claim about a real Essential Designs customer or a tested production system:
| Step | Action | Evidence the reviewer should request |
|---|---|---|
| 1 | Open the reservation in two independent sessions | Both sessions show the same starting revision |
| 2 | Change the date in the first session and save | The stored date and record revision change |
| 3 | Change the entrance in the second, older session | The application still knows which revision that edit began from |
| 4 | Submit the second session | The agreed stale-save rule runs before an overwrite can occur |
| 5 | Resolve the conflict and reopen the reservation | The final date and entrance match the deliberate resolution |
Ask the delivery team to demonstrate the stored outcome, not just a success banner. This exercise is a requirement rehearsal; its inputs are invented and it produces no benchmark or performance claim.
Put the freshness condition at the write boundary
A screen can check for changes when it loads, yet become stale a second later. A separate check immediately before saving can also leave a gap if another writer changes the record between that check and the update.
The implementation needs an indivisible decision: update only if the stored revision still matches the revision supplied with the edit. The exact mechanism belongs with the application's architecture. A version column and conditional database update is one possible design; it must not become an unprotected read followed by an unconditional write.
For an HTTP API, the standard provides a relevant building block. RFC 9110's If-Match condition lets a request depend on the current representation matching a supplied entity tag. MDN's If-Match documentation explains its use against lost updates and the strong comparison requirement. An unmet condition normally results in a 412 Precondition Failed response.
That protocol response is not the entire product feature. The server still has to enforce the condition correctly, and the application has to help the person recover. An entity tag is not a human explanation of what changed.
Where an application already has an API integration contract, add the stale-write rule to it. The contract should say which revision a client sends, what rejection means and whether retrying requires a fresh user decision.
Decide what the second editor can do
Essential Designs recommends treating the recovery path as part of the business requirement. A message that merely says "something went wrong" hides an important distinction: the proposed edit may be valid, but it was based on information that is no longer current.
Preserve the draft where the design permits it. Show the current saved values alongside the person's proposed values, or provide a clear way to reopen the current record without losing the work they need to review. Explain that another save changed the record, rather than blaming the person's connection.
Then name the allowed choice. The person might reload and reapply a change, ask the record owner to resolve it, or explicitly confirm a new combined version. Do not add a casual "overwrite anyway" shortcut if the business has not agreed who may make that decision.
This is not a recommendation to expose another person's private information. The conflict view should respect the application's existing access rules; detailed permission design is outside this note.
Different fields may still describe one business decision
It can be tempting to merge edits automatically whenever the field names differ. In the booking example, however, the date and entrance may be related: a loading bay might only be available on certain days.
Before approving automatic merging, identify relationships the application must revalidate. A price and discount, a delivery date and vehicle assignment, or an order quantity and stock allocation can each form a coupled business decision. Non-overlapping text changes do not prove the resulting record is valid.
Keep the initial requirement simple enough to verify. A deliberate conflict review may be more suitable than an elaborate merge interface for a low-volume internal tool. For a different workflow, frequent simultaneous work may justify field-level rules or a collaborative editing model. Select the behaviour from the real task rather than adding complexity for its own sake.
Follow every route that can change the record
The browser form is only one possible writer. A scheduled import, administrator tool or connected application may update the same reservation. A well-behaved front end cannot compensate for another route that ignores the shared rule.
List the writers in the software requirements. For each, identify the record boundary, revision condition, failure response and person or process responsible for resolution. Confirm what happens to a batch when one row is stale: a partial result must not masquerade as complete success.
Rehearse at least a same-field collision, a related-field collision and a record that disappears before the second save. Also try two submissions close together. The expected behaviour should be agreed in advance, not inferred from whichever update happened to finish last during a demonstration.
For an existing application, include these cases in the support and improvement backlog. Describe the affected workflow and evidence before assuming that a full replacement is necessary.
Accept a deliberate outcome, not merely a saved form
The useful buyer decision is whether the shared record remains trustworthy when ordinary work overlaps. A successful save is insufficient evidence if it silently reverses another accepted change.
Ask for the two-editor rehearsal, the server-side condition and the recovery journey as one coherent feature. Keep this requirement visible when planning custom business software, even when concurrent editing is uncommon rather than constant.
Discuss your shared-record workflow with Essential Designs if a new or existing application needs clearer write rules. Bring one representative record and the tasks people perform on it, without sharing sensitive production data.
Sources and scope
RFC 9110 and MDN support the stated HTTP semantics only. The equipment reservation, acceptance sequence and product recommendations are original illustrative editorial work, not customer evidence, a security assessment or a claim that one mechanism fits every application.
Reviewed October 14, 2026. Recheck the protocol references, application links and implementation assumptions by January 14, 2027. Revise the rehearsal when the actual record or write routes change.
