How can two staff edit the same product without silently losing one change?

Define what an edit can overwrite

Imagine a small retailer where one staff member corrects a product’s dimensions while another changes the shipping note. Both open the same catalogue form at 10:00. The first saves at 10:05; the second saves at 10:07 from a stale copy. If the application replaces the entire record with the second form, the dimension correction disappears even though both screens may report success. A later complaint looks like a data-entry mistake, but the real failure is an unexamined concurrent write. Identify which fields are edited together, which downstream pages or feeds consume them, and whether a single save replaces a whole product or only a field. That determines the smallest unit that needs conflict control.

The HTTP standard provides a conditional request mechanism for this problem. A representation can carry an entity tag, commonly called an ETag, and an update can send that tag in an If-Match header. RFC 9110 describes If-Match as a way to prevent the lost-update problem when agents act in parallel. The server compares the supplied tag with its current representation before applying the state-changing method; a failed condition ordinarily leads to 412 Precondition Failed. This is different from using If-None-Match on a public GET to save bandwidth. The editor is asking whether their old copy is still the current basis for a write.

Make the save conditional and atomic

When the edit form loads, give it the current product data and a version token for exactly the representation that the save endpoint will update. On Save, send the token with the proposed change. The origin must recheck the token against the current record at the point of writing, within the same transactional boundary as the update. A check in browser JavaScript, or a separate read followed by an unprotected write, leaves a race. Do not let a weak ETag stand in for this check: the HTTP If-Match comparison uses the strong comparison algorithm. If a system has no HTTP endpoint for a staff form, an equivalent database version column and conditional update can implement the same business rule, but it should not be described as an HTTP If-Match exchange unless it actually is one.

Decide what happens when the client omits the token. If the product endpoint requires a precondition for updates, RFC 6585 defines 428 Precondition Required for that policy; its response should explain how to submit a conditional request. A supplied tag that no longer matches is a different case: the server must not silently apply the stale change, and the ordinary response is 412. Do not turn every validation error or permission denial into a conflict message. First check the staff member is allowed to edit the product and that the proposed fields are valid; then evaluate the precondition as the standard specifies. Record the result in an audit trail that identifies who attempted the edit and which product version was involved, without storing unnecessary sensitive form content.

Consider field scope carefully. A single product ETag is simple but will flag a conflict even when staff edited different fields. That can be acceptable for a small catalogue because it makes every change visible. A finer version per field or per component may reduce unnecessary conflicts, but only if the server can prove the untouched data will not be overwritten and dependent fields remain coherent. Price, tax display, availability and offer copy may depend on one another; merging them independently can create an impossible listing. Start with a whole-record guard, observe real conflict cases, then refine only where a clear editorial rule exists. Complexity is justified by a safer decision, not by avoiding every interruption.

Give staff a usable conflict decision

A 412 response is only the technical stop. The staff interface should keep the unsaved entries and show the current saved values beside the attempted values. State who or what last changed the record if that information is reliable and appropriate; do not invent a named editor from incomplete logs. Offer deliberate actions such as copy one value, reload the current product, or submit a reviewed merged version with a fresh token. Never automatically retry the same whole-form payload with the new token, because that converts the stopped overwrite into an intentional-looking overwrite. The person resolving the conflict needs to understand consequences for customer-visible details and any pending fulfilment, not merely click Save again.

Test with two real browser sessions. Open the same product in both, change one meaningful field in the first session and save, then try to save an older form in the second. Verify that the second request cannot erase the first change, that the attempted text remains available, and that the conflict screen displays the latest persisted values. Repeat with a price-related field, an inventory-related field and a harmless description field, because merging rules may differ. Test missing tokens, weak tags, stale tags, deleted products and a retry after a network timeout. A genuine success path must show that a reviewed merge uses the new current token and leaves one coherent product record.

For a worked decision, return to the dimensions and shipping-note example. Staff A’s corrected dimensions are now current; Staff B’s proposed shipping note remains unsaved. The conflict view shows both changes, and B confirms that the new dimensions do not alter the shipping rule. B keeps A’s dimensions, adds the new note, and saves against the fresh product version. If the note had promised shipping that the corrected dimensions make impossible, B would escalate the fulfilment decision instead. The protected outcome is not merely two successful HTTP requests. It is a product page that reflects a reviewed combination of facts and leaves staff able to explain how it got there.

Keep the surrounding workflow consistent

The product editor should tell staff what a successful save means. A record may be saved in the catalogue database while search indexes, storefront caches or marketplace feeds are still updating. Conflict prevention protects the source record; it does not guarantee every channel already shows the latest value. Show an honest pending or published state if the business has asynchronous distribution. If a price correction is urgent, define who checks the public page and any external listings after the guarded update. Without that handoff, staff may mistake a correct 200 response for proof that every customer has seen the new price.

The guard must cover automated writers as well as humans. A nightly supplier import, stock synchronisation or campaign tool can modify the same product while a staff member has a form open. Give each writer a defined authority and update scope. If an import deliberately replaces a set of fields, ensure the staff conflict view identifies that source accurately and allows the employee to review its effect. A background process should not bypass version checks simply because it has no screen. Conversely, a system may use a controlled merge for truly independent fields, provided its dependency rules are explicit and testable. The invariant is that a stale writer cannot silently erase another accepted change.

Choose a recovery path for work that cannot be merged in the browser. A regulated description, contractual product specification or price change may need a second approver. Preserve the attempted draft separately with access limited to authorised staff, mark it as not published, and route it to the person who can decide. Set a practical retention rule for abandoned conflict drafts so they do not become an invisible parallel catalogue. Do not copy a failed edit into the live product merely to avoid losing staff effort. The interface can let the editor copy the proposed text while the approval workflow determines whether it should become customer-facing.

Finally, make the conflict messages understandable to staff who do not know HTTP. Say that the product changed after they opened it, identify what remains unsaved, and offer the next safe action. Keep the protocol status in logs and developer diagnostics. During a rehearsal, ask a catalogue colleague to resolve the worked example without coaching; observe whether they preserve the corrected dimensions and make an informed shipping decision. If the person cannot tell which value will appear publicly, the user interface is not finished even if the conditional request behaves perfectly.