Example Scenario

Understanding the lost update problem requires more than definitions—it demands seeing the anomaly unfold in realistic contexts. In this page, we'll walk through comprehensive scenarios across multiple domains, tracing each operation precisely to understand exactly how updates become lost.

These scenarios are not simplified toy examples. They represent the actual patterns that occur in production systems, with enough detail to recognize similar situations in your own work.

Business Context:

Maria has a checking account with $500. She is at an ATM withdrawing $100 for dinner. Simultaneously, her landlord's automatic rent deduction of $400 is being processed by the bank's batch system.

The Players:

• Transaction T₁ (ATM Withdrawal): Deducts $100 from Maria's account
• Transaction T₂ (Automatic Rent Payment): Deducts $400 from Maria's account

Initial Database State:

Expected Outcome:

If these transactions execute correctly (in any order):

• Initial: $500
• After T₁: $500 - $100 = $400
• After T₂: $400 - $400 = $0
• OR After T₂ then T₁: $500 - $400 - $100 = $0

Maria's account should reach $0 regardless of transaction order. Now let's trace what actually happens when the transactions interleave incorrectly:

Critical Moment Analysis:

The lost update occurred because both transactions read the same stale value ($500) before either could write. When T₂ computed its update at 09:00:00.018, it used $500 instead of $400 (T₁'s pending result). This is the fundamental pattern: reads from overlapping time windows create stale-data foundations for writes.

The Audit Trail Paradox:

Making this worse, the transaction log will show both operations:

09:00:00.020 - T₁: UPDATE accounts SET balance = 400 WHERE account_id = 'ACC-7821'
09:00:00.022 - T₂: UPDATE accounts SET balance = 100 WHERE account_id = 'ACC-7821'

An auditor seeing this log will be confused: T₁ set balance to $400, then T₂ set it to $100. The auditor expects $100 final. But both operations should have worked—the log doesn't reveal that T₂ used a stale premise. The audit trail is technically accurate but semantically misleading.

Business Context:

An online electronics retailer launches a flash sale on a popular gaming console. Only 5 units remain in stock. At 10:00 AM, when the sale goes live, 200 customers simultaneously attempt to add the console to their carts and checkout.

The Simplified Scenario:

To illustrate the core problem, let's trace just three concurrent purchase transactions:

• Transaction T₁ (Customer Alice): Purchasing 1 unit
• Transaction T₂ (Customer Bob): Purchasing 1 unit
• Transaction T₃ (Customer Carol): Purchasing 1 unit

Initial Inventory State:

Expected Outcome:

With 5 units and 3 customers, all three should successfully purchase, leaving 2 units remaining:

• Initial: 5 units
• After T₁, T₂, T₃: 5 - 1 - 1 - 1 = 2 units

Problematic Execution:

The Cascading Business Impact:

1. Customer Service Crisis: 45+ customers receive "out of stock" emails days after receiving confirmation
2. Refund Processing: Finance must process refunds, potentially with additional compensation
3. Marketing Damage: Social media complaints about "bait and switch" tactics
4. Competitor Advantage: Frustrated customers go to competitors for future purchases
5. Legal Risk: In some jurisdictions, selling unavailable inventory is consumer fraud

Why This Pattern is Common:

The read-then-check-then-write pattern is natural for developers:

// Naive implementation - vulnerable to lost updates
const stock = await db.query('SELECT quantity FROM inventory WHERE sku = ?', [sku]);

if (stock.quantity >= requested) {
    // DANGER ZONE: Another transaction can modify stock between SELECT and UPDATE
    await db.query('UPDATE inventory SET quantity = ? WHERE sku = ?', 
                   [stock.quantity - requested, sku]);
    await createOrder(...);
}

The "DANGER ZONE" comment highlights the vulnerable window—the time between reading and writing where other transactions can slip in their own modifications.

Business Context:

A content platform tracks article page views to determine content popularity from revenue sharing with authors. Popular articles mean higher author payments. The view counter is updated every time a user loads an article.

The Pattern:

Counter increments are the most elemental example of read-modify-write:

-- Read current count
SELECT view_count FROM articles WHERE article_id = 'A-123';
-- Result: 1000

-- Modify (application layer)
new_count = 1000 + 1

-- Write updated count
UPDATE articles SET view_count = 1001 WHERE article_id = 'A-123';

This seems straightforward. What could go wrong?

Scenario: Viral Article Peak Traffic:

An article goes viral. During peak hour, 10,000 users view the article within a 10-minute window. If the database receives 1,000 concurrent increment requests and 10% experience lost updates due to timing, 100 views are lost.

Let's trace a specific collision:

Why Counters Are Especially Vulnerable:

Counter operations have these characteristics that maximize lost update risk:

1. High Frequency: Popular resources receive many updates per second
2. Simple Pattern: Every operation follows the same R→M→W sequence
3. Same Computation: Every operation adds the same value (usually 1)
4. No Business Logic Delay: Unlike orders that require validation steps, counters are fast—so more can collide

The Mathematically Correct Counter Value:

Let N = number of increment operations Let C = number of collisions (overlapping R→W windows)

If no lost updates: final_count = initial + N With lost updates: final_count = initial + (N - C)

For high-traffic counters, C can be 5-15% of N without proper concurrency control.

Business Context:

A corporate office uses an internal booking system for conference rooms. The system tracks availability using a boolean is_available flag and a booked_by field.

The Booking Logic (Vulnerable):

Concurrent Booking Attempt:

Two managers, Sarah and Tom, both need the large conference room for a 2 PM client meeting. They click "Book Now" at almost exactly the same moment.

Organizational Impact:

This isn't just a scheduling inconvenience:

1. Client Perception: External clients witness internal chaos—unprofessional appearance
2. Meeting Disruption: Sarah's meeting either starts late or happens in an inferior room
3. Trust Erosion: Employees stop trusting the booking system; resort to paper signup sheets
4. Help Desk Load: IT receives complaints about a "buggy" booking system
5. Executive Attention: If high-profile meetings are affected, the issue escalates

The fundamental problem: the system gave confirmations that it couldn't honor. Distributed trust was violated.

Business Context:

An airline booking system allows passengers to select specific seats. A flight from New York to London has one first-class seat remaining: 2A, a window seat near the front.

The Race Condition in Seat Selection:

Two frequent flyers, James and Elena, both browse the seat map. Both see seat 2A highlighted as available. Both click to select it. This scenario involves a slightly different lost update pattern—where the "update" is marking a seat as taken.

The Gate Agent Nightmare:

At boarding time:

1. James presents boarding pass showing seat 2A
2. Elena presents boarding pass showing seat 2A
3. System shows Elena in 2A
4. James's confirmation email proves he selected the seat
5. Gate agent must manually re-seat one passenger
6. First class is full; James is downgraded
7. Compensation required; customer loyalty damaged

Why This Pattern is Pernicious:

The "assignment" operation seems like a simple write, but it's actually a conditional write predicated on reading the current state. The logic is:

IF current_state == AVAILABLE:
    new_state = ASSIGNED to ME

When two transactions execute this logic concurrently with interleaved reads and writes, one assignment is lost. The seat cannot belong to both passengers—one will be disappointed.

Across all five scenarios, the same fundamental pattern emerges. Recognizing this pattern in your own code is essential for prevention.

We've explored five detailed scenarios demonstrating the lost update problem across different domains. These aren't contrived academic exercises—they represent the actual failure modes that occur in production systems every day.

What's Next:

Now that we've seen how lost updates manifest in realistic scenarios, the next page examines the deeper consequences: how lost updates corrupt data integrity, violate business invariants, and compound into systemic data quality problems over time.