2 requests.
2 successful transactions.
0 database errors.
And the application can still end up in an 𝗶𝗻𝘃𝗮𝗹𝗶𝗱 𝘀𝘁𝗮𝘁𝗲.
Imagine an internet application where 𝗮𝘁 𝗹𝗲𝗮𝘀𝘁 𝗼𝗻𝗲 𝘀𝗲𝗿𝘃𝗶𝗰𝗲 𝗲𝗻𝗱𝗽𝗼𝗶𝗻𝘁 𝗺𝘂𝘀𝘁 𝗿𝗲𝗺𝗮𝗶𝗻 𝗲𝗻𝗮𝗯𝗹𝗲𝗱.
There are 2 enabled endpoints.
Request A checks the database → “2 are enabled.”
It disables Endpoint A.
Almost at the same time:
Request B checks the database → “2 are enabled.”
It disables Endpoint B.
Both transactions commit successfully.
Now 𝟬 𝗲𝗻𝗱𝗽𝗼𝗶𝗻𝘁𝘀 𝗮𝗿𝗲 𝗲𝗻𝗮𝗯𝗹𝗲𝗱.
The database says “𝘀𝘂𝗰𝗰𝗲𝘀𝘀.”
The application says “𝗳𝗮𝗶𝗹𝘂𝗿𝗲.”
This is 𝗪𝗿𝗶𝘁𝗲 𝗦𝗸𝗲𝘄.
𝗪𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗵𝗮𝗽𝗽𝗲𝗻𝗲𝗱?
The transactions read overlapping state but 𝘄𝗿𝗶𝘁𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗿𝗼𝘄𝘀.
A database may detect two transactions writing the same row, yet still allow concurrent transactions that modify different rows.
The problem is not an individual write.
The problem is the 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗿𝘂𝗹𝗲 𝗮𝗰𝗿𝗼𝘀𝘀 𝗺𝘂𝗹𝘁𝗶𝗽𝗹𝗲 𝗿𝗼𝘄𝘀.
𝗪𝗵𝘆 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀 𝗺𝗶𝘀𝘀 𝗶𝘁
A common assumption is:
“It's inside a transaction, so it's safe.”
Not necessarily.
The result depends on the database's isolation guarantees, transaction behavior, and how the invariant is represented.
Snapshot-style isolation can allow this kind of anomaly.
𝗛𝗼𝘄 𝗰𝗮𝗻 𝗶𝘁 𝗯𝗲 𝗽𝗿𝗲𝘃𝗲𝗻𝘁𝗲𝗱?
Depending on the database and workload:
• 𝗦𝗘𝗥𝗜𝗔𝗟𝗜𝗭𝗔𝗕𝗟𝗘 isolation
• Explicit locking of relevant state
• Database constraints where possible
• Transaction designs that prevent conflicting decisions
Stronger consistency can also mean 𝗺𝗼𝗿𝗲 𝗰𝗼𝗻𝘁𝗲𝗻𝘁𝗶𝗼𝗻, 𝗹𝗮𝘁𝗲𝗻𝗰𝘆, 𝗮𝗻𝗱 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗿𝗲𝘁𝗿𝗶𝗲𝘀.
𝗖𝗼𝗺𝗺𝗼𝗻 𝗺𝗶𝘀𝘁𝗮𝗸𝗲
Checking whether every transaction succeeded.
The better question is:
“𝗖𝗮𝗻 𝘁𝘄𝗼 𝘀𝘂𝗰𝗰𝗲𝘀𝘀𝗳𝘂𝗹 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻𝘀 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿 𝗯𝗿𝗲𝗮𝗸 𝗮 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗿𝘂𝗹𝗲?”
𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆
A successful transaction does not automatically mean a 𝘃𝗮𝗹𝗶𝗱 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝘀𝘁𝗮𝘁𝗲.
What’s your perspective on Write Skew? Share your technical view in the comments. Follow me for more backend and distributed-systems content, and subscribe for longer discussions.
#WriteSkew #Database #DatabaseDesign #TransactionIsolation #Concurrency #BackendEngineering #SystemDesign #DistributedSystems #SoftwareEngineering #Reliability #Scalability #DataEngineering #DevOps #Python #TechCareers #TechnologyLeadership #TechTalent
