Switch to the primary to compute issuable updates
A customer has reported closely-timed labels updates were frequently overwriting each other's update. See this issue - internal only for more details.
Switching to the primary DB host to read and compute the updated values for an issuable might abate the issue.
To completely address the issue, the target issuable should be locked for update. Locking an issuable requires a significant refactor of the update service and should be done if switching to the primary DB for reads does not sufficiently address the issue.
Edited by euko