Last-write-wins

As explained in ScyllaDB in Action

Last-write-wins is a conflict-resolution technique that retains the value from the most recent write when updates conflict.

Last-write-wins is ScyllaDB’s default way to reconcile conflicting writes. Each non-primary-key value is stored as a cell with a microsecond-precision write timestamp. When replicas hold different versions of that cell, the value carrying the latest timestamp wins and is eventually replicated as the final value. The number of replicas that first acknowledged a write does not decide the winner. section 6.1.2

This rule is simple and predictable, but it can lose a valid update. If Edith updates an author bio with QUORUM consistency and Emily writes a different bio milliseconds later with ONE consistency, Emily’s later timestamp wins even though Edith’s write reached more replicas. Last-write-wins considers timestamps, not editor intent, messages, or other application context. section 6.1.2

Work with write timestamps deliberately when the ordering of updates matters:

• Inspect a column’s stored timestamp with WRITETIME(column) to see which version is eligible to win. section 6.1.2 section 6.6
• Override the default coordinator-based timestamp with USING TIMESTAMP on an UPDATE or INSERT when a write needs a specific ordering. section 6.1.2 section 6.6
• Use conditional updates through lightweight transactions when an update must depend on the row’s current state rather than simply accepting the latest write. section 6.5
• Consider client-side coordination, such as distributed locking, when preserving context across concurrent edits matters. section 6.1.2

Protecting a live update during migration

A migrator can conflict with an application that is dual-writing during a database move. It may read an older article, then insert that copy after an editor has changed the article. If the migration insert has the higher timestamp, it overwrites the editor’s newer data. Set USING TIMESTAMP to a value no later than the moment migration reads begin; preferably use the source database’s write or modified timestamp. That lets subsequent live updates retain later timestamps and win. section 12.2.4

Figure 6.1 In Scylla, the write timestamp of a query takes precedence over the number of replicas a node is stored on.

Compare the two concurrent writes: a later write timestamp wins even when an earlier write was acknowledged by more replicas. section 6.1.2

How ScyllaDB in Action covers it

How deep it goes

Explains per-cell microsecond timestamps, WRITETIME inspection, timestamp overrides, lost writes, and migration ordering without detailing replica internals.

Examples

Uses competing author-bio edits and a dual-writing article migration that can overwrite a live editor update.

What you can do after

Operate/configure it by inspecting WRITETIME values and supplying USING TIMESTAMP values for ordered writes and migrations.

How it connects

Connects eventual consistency and consistency levels with write timestamps, conditional updates, lightweight transactions, and distributed locking.

liveBookmanning.com

Read ScyllaDB in Action on liveBook Get the book at manning.com

Related concepts

• timestampuses · A timestamp is a value representing a specific point in time, typically associated with an event, observation, or data item.
• write timestampused by · A write timestamp is a timestamp attached to a data write to establish its ordering relative to other writes.
• optimistic concurrency controlalternative to · Optimistic concurrency control is a concurrency-control technique that allows operations to proceed with limited locking and detects conflicting changes through validation before committing updates.
• memoryused by · Memory is a storage resource or mechanism that retains data or computational state for access during computation or later use.
• lightweight transactioncontrasts with · A lightweight transaction is a conditional database operation that uses distributed consensus to verify a condition and apply a mutation atomically with respect to competing requests.

This explainer was generated by Manning's knowledge graph from the text of ScyllaDB in Action. The section links point to the parts of the book it draws on.