Imagine an internet application where 𝗮𝘁 𝗹𝗲𝗮𝘀𝘁 𝗼𝗻𝗲 𝗮𝗱𝗺𝗶𝗻𝗶𝘀𝘁𝗿𝗮𝘁𝗼𝗿 𝗺𝘂𝘀𝘁 𝗿𝗲𝗺𝗮𝗶𝗻 𝗮𝗰𝘁𝗶𝘃𝗲.
Two administrators are active.
At almost the same time:
Transaction A checks: “2 active admins.”
→ Deactivates Admin A.
Transaction B checks: “2 active admins.”
→ Deactivates Admin B.
Both transactions succeed.
Now there are 𝟬 𝗮𝗰𝘁𝗶𝘃𝗲 𝗮𝗱𝗺𝗶𝗻𝘀.
No transaction necessarily violated its own logic.
The combination violated the business rule.
This is 𝗪𝗿𝗶𝘁𝗲 𝗦𝗸𝗲𝘄.
𝗪𝗵𝗮𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝗲𝗱?
The transactions read overlapping business state but write different rows.
Under snapshot-style isolation, both may read the same consistent snapshot.
Because they update different rows, there may be no direct write-write conflict to stop either transaction.
That is the trap.
𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀
Write skew appears in real applications involving rules such as:
- At least one active moderator must exist
- At least one service endpoint must remain enabled
- Two resources cannot both become unavailable
- A quota must remain above a minimum
Adding a transaction does not automatically make the business rule safe.
𝗛𝗼𝘄 𝗶𝘀 𝗶𝘁 𝗽𝗿𝗲𝘃𝗲𝗻𝘁𝗲𝗱?
Depending on the database and workload:
- Use SERIALIZABLE isolation where appropriate
- Explicitly lock the rows/state that represent the invariant
- Encode the rule as a database constraint when possible
- Design the transaction so conflicting operations cannot proceed independently
Serializable execution may detect the dangerous dependency and abort one transaction, requiring an application retry.
The trade-off is real: stronger consistency can mean more contention, blocking, or transaction retries.
𝗖𝗼𝗺𝗺𝗼𝗻 𝗺𝗶𝘀𝘁𝗮𝗸𝗲
Engineers often check:
“Did both transactions succeed?”
The better question is:
“Can two individually valid transactions produce an invalid combined state?”
𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆
Write skew happens when separate valid writes collectively break a business invariant.
What’s your perspective on this concurrency problem? Share it in the comments. Follow for more practical backend and distributed-systems engineering posts, and follow me for longer technical discussions.
#WriteSkew #Database #DatabaseDesign #TransactionIsolation #Concurrency #BackendEngineering #SystemDesign #DistributedSystems #SoftwareEngineering #Scalability #Reliability #DevOps #DataEngineering #Python #TechCareers #TechnologyLeadership #TechTalent
