Write Skews can be avoided by Materializing Conflicts

Write Skews happen because the two transactions that run concurrently end up changing different objects. If they were updating the same object, then we could have prevented write skews by using Atomic Writes or Explicit Locks.

We can force this to happen by creating concrete rows in the database and getting the transactions to update the same objects (or rows) concurrently.

Take the example of a Meeting Room Booking application. Two transactions running concurrently result in conflicting bookings (i.e., bookings for the same room with an overlapping time range) because no bookings were found when the transactions executed their initial queries.

This situation can be avoided by pre-populating a table with time slots and rooms for a duration in time (say six months). Each transaction can then lock the rows during the operation, forcing other transactions to wait to execute their first data fetch.

A problem with this approach is that we now have to pre-populate the slots table to avoid concurrency issues later. So we have allowed a database concern - concurrency - to leak into our application data model. Hence this approach is best treated as a last resort and avoided as much as possible.