Two users edit the same record. How would your full-stack feature avoid silently losing changes?

Handle stale form data and concurrency conflicts

Explains stale edit detection, row versioning, conflict UI, refresh behavior, and safe update contracts.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would include a concurrency token, such as a row version or updated-at value, when the form loads. The update request sends that token back. If the database row changed since the user loaded it, the API returns a conflict response instead of overwriting the newer change. The UI explains that the record changed, shows the latest data, and lets the user reload, compare, or reapply their edits depending on the domain.

Full answer below

Practice focus

Optimistic concurrency, version tokens, update DTOs, conflict responses, merge UX, and user recovery.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Stale forms are where frontend convenience and backend correctness meet. The system needs to protect data without giving users a mysterious failure.
I would include a concurrency token, such as a row version or updated-at value, when the form loads. The update request sends that token back. If the database row changed since the user loaded it, the API returns a conflict response instead of overwriting the newer change. The UI explains that the record changed, shows the latest data, and lets the user reload, compare, or reapply their edits depending on the domain.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would make the conflict response useful. It can include current server values, changed fields, and the user's submitted values where safe. For simple records, reload-and-retry may be enough. For longer forms, field-level merge UI or draft preservation can save work. Partial updates help, but they do not remove the need for concurrency checks when fields interact or when business rules depend on the whole record.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using last-write-wins without noticing data loss.
No concurrency token in the edit contract.
Discarding the user's submitted values after a conflict.
Showing a generic error for a recoverable conflict.

Two users edit the same record. How would your full-stack feature avoid silently losing changes?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Technologies

Tech stacks

Skill areas

Suggest an improvement