A more realistic analogy is where you are logging medicine given to a patient. You shouldn’t give the second medicine after the first one. But here it’s no good to know after the event that you’ve done wrong, you need to have self-refreshing or self-expiring screens to get the latest possible updates. But that’s a different thing altogether.

The solution – optimistic concurrency – only works where you can undo your actions, and it only scales where the number of people accessing a record at one time doesn’t go as the number who can access it.

There are no end to ways that increasing numbers can effect the nature of the problem. Part of the reason for optimistic concurrency in a large group is to lower the costs of coordinating the binding of tallent to problems – so a large group running optimistically can get the best talent to pick up the problem they are best suited for at minimum cost. The jerk problem is real, but it’s not the only thing who’s probability rises as the size of the pool of workers enlarges.

2) Optimistic concurrancy seems to not be so scale free sometimes since once the group size gets large enough it includes at least one jerk.