Last-Write-Wins - ScenarioX

1. What exactly is Last-Write-Wins?

Your ASP.NET Core API lets two different clients each write an update for the same row in Azure SQL, around the same time. If the API just keeps whichever update arrives last, it's assuming that whatever arrives last also happened last. That's not always true.

A slower network, or a delay anywhere along the way, can make an older update reach the API after a newer one already has. The older update then overwrites the newer one in Azure SQL, and nothing even records that it happened.

Whichever update arrives last wins, even when it isn't the one that actually happened last. That's exactly what timestamp-based last-write-wins fixes.

2. How would you fix it in Azure?

Timestamp-based last-write-wins fixes the assumption: add a column to the Azure SQL table that records when each update actually happened, not when it reached the API. Before saving an incoming update, compare its timestamp to the value already stored, and save it only if it's newer, otherwise discard it and keep the row as it is.

Compare timestamps, not arrival order, so the update that actually happened last is the one that wins.

3. How can you visualize it in everyday terms?

Two letters arrive in your mailbox on the same day: one written a week ago and delayed in the mail, one written yesterday. Opening whichever letter you happen to pick up last would make you trust the older news.

Checking each letter's postmarked date instead, and believing whichever one is dated more recently, gives the right answer no matter which order they arrived in.

Trust the date something happened, not the order it showed up.