Hi, Paul.
Sounds like you're talking about REST API. And that your are overwriting data with older values if B managed to read record before A finished to update it. Classic conflict resolution case where 2 sides write same field and last writer wins.

1 - Can't you PATCH only the few updated fields instead of the whole record? >> Efficient if A and B updates different fields in the record.

2 - IF integrated app always sends 2 subsequent async calls - can't you put them together in one call? As in both local updates are merged in the app before getting pushed to SERP?

3 - IF calls can randomly sometimes happen "too close" (like 2 users from different devices) working with same record. The right before doing a write call, do one more read call to fetch record's sequence number. If @sequence is the same then safe to update, and if @sequence has changed then fetch new record version and deal with conflicts in the integrated app's side.


4 - Lock is tricky - could do: check lockFlag -> IF true, then try later | IF not then write lockFlag -> read -> update -> if successful update -> remove lockFlag
!! but then should handle "forever/incorrectly" locked cases
!! I would avoid file-approach


---
But you also mentioned non-updating and qupdating which sounds like HAL web functions are the ones receiving web calls (not REST API).
If that is the case, then look in HAL how ComparePosts is used as condition before RecordUpdate.