Archivestorage
Object Storage Consistency: What You Can Actually Rely On
Modern object stores are strongly consistent for new writes, but listings, caches, and multipart uploads have edges.
- Published
- Reading time
- 1 min read
Object storage (S3 and compatible systems) historically offered read-after-write for new objects and eventual consistency for overwrites and listings. Modern S3 is strongly consistent for all read/write operations, but the ecosystem around it is not uniform.
What to assume
- PUT then GET of the same key: strongly consistent in current S3; verify your provider.
- LIST: may be paginated and, on some providers, slightly stale.
- Multipart uploads: incomplete parts are invisible until completed; abort them or pay for storage.
- Cross-region replication: asynchronous; reads in the replica region can lag.
The practical rules
- Never use LIST as a source of truth for existence; do a HEAD or GET.
- Make writes idempotent — retries are normal and conditional writes (
If-None-Match) help. - Versioning plus lifecycle rules beats in-place overwrite for audit and recovery.
Takeaway: treat object storage as a key-value store with strong per-key semantics and weak aggregate semantics. Design around the difference.