Skip to content

PATTERN Cited by 2 sources

Conditional Write (Compare-and-Set on Storage)

A conditional write is a storage-layer primitive that performs a write (typically PUT) only if a precondition on the current state of the target is satisfied — usually an If-Match against an etag or version, or an If-None-Match: * for "only if this key doesn't already exist." It is compare-and-set for objects: the storage system atomically decides whether to apply the write, eliminating the read-modify-write race.

Why this pattern matters

Without conditional writes, multi-writer coordination on an object store is expensive: customers invent external locking (distributed locks, coordinators, lease servers), version fencing (write-then- verify patterns), or single-writer topologies (one-process- per-bucket / per-prefix). All of these are code the application team owns, maintains, and debugs.

Conditional writes let the storage layer own the atomicity, and let the application express intent directly: "commit this snapshot only if no one else has committed since I read."

S3 context

S3 shipped conditional-write enforcement on general-purpose buckets in 2024. Warfield's 2025 post reports the customer reaction:

"In the past year, as we've started to roll out conditional operations we've had a very similar reaction [to the 2020 strong-consistency rollout]."

The "similar reaction" is the code-deletion one: external locking primitives get retired. Compare concepts/strong-consistency.

(Source: sources/2025-03-14-allthingsdistributed-s3-simplicity-is-table-stakes)

Why it needs strong consistency underneath

Conditional writes only work if the precondition check sees an up-to-date view of the target. On an eventually-consistent store, the precondition might be evaluated against a stale replica, which undermines the "atomicity" claim entirely. S3's 2020 move to concepts/strong-consistency is therefore a prerequisite for the 2024 conditional-writes rollout — the ordering of those two features is not accidental.

Common applications

  • Iceberg / Delta / Hudi snapshot commits — the snapshot-pointer update is the atomic moment that makes the table transactional over immutable objects. Conditional writes remove the need for an external catalog lock. See systems/apache-iceberg.
  • Leader-election / token-holder files — "I'm the leader, seen version V" — conditional PUT to advance the token fails if someone else advanced it first.
  • Time-based single-writer leases — CASAAS. 2025-05-20 Fly.io Litestream revamp uses S3/Tigris conditional writes to enforce one active replication writer per destination, retiring LiteFS's original Consul dependency for the single-leader constraint.
  • Idempotent object creation — If-None-Match: * semantics prevent two writers both thinking they "created" an object.
  • Versioned configuration stores — atomically advance a config document only if the reader's cached version matches.

Trade-offs

  • Precondition-failure handling. The client must be prepared to re-read, reconcile, and retry on a failed precondition. Conditional writes don't eliminate coordination cost; they move it out of storage and into application logic, which is the right place for it.
  • Write amplification on contention. Hot-key contention translates into retry loops; conditional writes work well for low-to-moderate write contention and poorly for high-contention fan-in (use a queue or a serialisation layer instead).

Seen in

Last updated · 200 distilled / 1,178 read