Read and write transactions arriving concurrently to affect the same record will queue up. Updates to the record acquire a record lock ahead of modifying it, so there really is no case where two writes happen concurrently. The depth of this queue is controlled by the
transaction-pending-limit, and by default it is 20. More than this number of concurrent transactions on the same record will return an error code 14, ‘key busy’. This is the so-called ‘hot key’ condition. Seach for hot key on the site for more information and solutions.
By default these two writes will be merged on the server-side. You can control this behavior through the exists write policy. You can also use the record’s generation to implement a check-and-set pattern to ensure that records do not get merged automatically on the server-side, but instead fail if another write came in before the one this client is trying.
I’ve used the python client for examples, but it happens on the server-side and any of the clients have these write policies.