Does a conflict mean both transactions must fail?

No. One may wait and later proceed, or one may succeed while another retries. The system's concurrency rules determine the outcome.

Does multiversion concurrency control eliminate writer conflicts?

No. Multiple versions can help readers, but concurrent modifications still need coordination according to the database's rules.

Is last-write-wins always suitable?

No. It can be an intentional policy, but arrival order may discard a meaningful update. Use it only when its consequences fit the data and application.

AI Glossary / Data engineering and architecture / Intermediate

Write - write conflict

Definition

A write - write conflict occurs when concurrent operations or transactions try to modify the same data item in ways whose ordering matters. The system must decide how those writes interact, for example by making one wait, rejecting a conflicting transaction, or applying a defined resolution policy. The conflict is a concurrency relationship; it does not automatically mean data corruption has occurred.

What it means

Imagine two people editing the same stored product description. Each change may be valid alone, yet saving both without coordination can cause one edit to replace the other. A database or application needs a rule that respects its intended meaning of an update.

The relevant data item depends on the system. Conflict detection may operate at a row, document, key, or another granularity. Two changes to different fields can still contend if the storage system coordinates the whole record. Conversely, separate records can participate in a broader business inconsistency without a direct write - write conflict on one item.

How it works

The system identifies overlapping modifications through mechanisms such as locks, version checks, or transaction validation. With locking, a second writer may wait until the first transaction completes. With optimistic checks, a writer may discover that the version it expected is no longer current and must reconsider its update.

The outcome depends on the database, isolation level, and operation. Some updates can be applied to the latest committed value; others are rejected and require a transaction retry. A distributed application may use a resolution rule, but that rule must match the business meaning.

Coordination is not only about preventing simultaneous physical writes. An application can read an old value, calculate a replacement, and later overwrite a newer value unless its complete read-and-update logic is protected appropriately.

Three practical examples

1. Catalog editing: Two editors revise the same description. A version check detects the second save against an outdated version and presents a reviewable conflict.

2. Inventory updates: Several requests reduce one stock quantity. The database operation must preserve the intended count and any availability condition under concurrent execution.

3. AI-assisted records: An assistant proposes a record update while a human changes that record. The application verifies the expected version before accepting the assistant's proposed replacement.

Think of it this way

Think of two people correcting the same paper form. If each works from a photocopy, putting the second corrected copy on top of the first can hide an earlier correction.

The analogy explains stale replacements. Its limit is that database systems can coordinate operations precisely, including waiting, checking versions, and retrying. Also, not every conflict should be merged automatically: two mutually exclusive status changes may require a business decision rather than combining words on a page.

Worked example

Suppose a stored quantity is 10 and its version is 7. Request A reads that version and plans to subtract 2, producing 8. Request B also reads version 7 and plans to subtract 3, producing 7.

A saves quantity 8 only if the version is still 7, then advances the version to 8. B's attempted replacement requires version 7, so it fails the condition instead of silently replacing A's result. B can reread quantity 8 and, if its business action remains valid, apply the subtraction to produce 5 with a new version.

Without appropriate coordination, writing the precomputed values 8 and 7 in succession could leave 7, losing A's change. The example is conceptual optimistic concurrency control; exact database syntax and transaction requirements depend on the implementation.

Illustrative case study

Fictional case: Conflict Orchard uses an assistant to standardize catalog descriptions overnight. A staff editor also corrects a product's safety wording during the same period. The assistant's draft was based on the earlier record.

The application initially saves generated descriptions as unconditional replacements. The team changes the process so every proposed replacement includes the version from which it was prepared. When the live record differs, the application preserves the human edit and sends the draft for comparison rather than assuming that the last arriving text is preferable.

This scenario illustrates update coordination. It is not a claim that a specific merge rule can determine the correctness of safety wording or any other substantive content.

Common misconceptions and mistakes

A common mistake is assuming that preventing simultaneous writes also protects every earlier read. A stale value computed in the application can still overwrite a later value when the final save lacks a suitable condition.

Another mistake is treating every conflict as an error that users should resolve manually. Some operations can safely retry or use an atomic update, depending on their meaning.

A lost update is one possible consequence of poorly coordinated modifications, not a synonym for every write - write conflict. Write skew is also distinct: a broader invariant can fail even when transactions modify different records.

Business use

Write - write conflicts matter wherever several services, users, or AI workflows modify shared records. The business requirement determines whether updates should wait, retry, merge, or return to a reviewer.

Measure contention, transaction aborts, retry volume, and unresolved editing conflicts. Keep transactions appropriately scoped and avoid holding coordination resources while waiting unnecessarily for external work. For generated updates, retain the source version and proposed change so reviewers can understand what became stale. The goal is preserving intended operations, not simply reducing the number of visible conflict messages.

Check your understanding

An assistant generated a replacement from version 4, but the record is now version 5. Is an unconditional save necessarily safe?

Answer: No. The assistant may overwrite changes it never saw. Check the expected version and apply the application's conflict or refresh policy before saving.

Related terms

Concurrency control
lost update
optimistic locking
row lock
transaction isolation
multiversion concurrency control
write skew
serialization failure

Learn next

Simulate two editors reading the same record, then saving in different orders. Add a version condition and record which save succeeds. Finally, decide whether the rejected edit should be retried, compared manually, or discarded based on its actual business meaning.

Sources

Sources: PostgreSQL, Transaction Isolation: https://www.postgresql.org/docs/current/transaction-iso.html, and Explicit Locking: https://www.postgresql.org/docs/current/explicit-locking.html. Read for concurrent-update behavior and lock coordination. PostgreSQL illustrates specific implementation choices; this entry does not generalize its exact isolation behavior to every database. Worked schedules and scenarios are original.

Previous: Wrapper Next: WYSIWYM (interaction technique)