Object store vs NFS consistency models

WHAT THIS TESTS The interviewer is testing real distributed-systems understanding: what consistency each model guarantees and how that shapes safe application design.

A GOOD ANSWER COVERS Contrast the granularity and mutation model. A modern object store now offers strong read-after-write consistency: once a PUT succeeds, any subsequent GET sees the new object. But the unit is the whole object, which is immutable, you replace it entirely, there are no partial in-place writes, and there is no built-in locking, so concurrent PUTs to the same key are last-writer-wins with no merge. A network file system like NFS exposes mutable files supporting partial writes and offers close-to-open consistency: a client opening a file sees writes that were flushed and closed before it opened, but concurrent writers to one open file can interleave bytes and there is no automatic coordination without advisory locks. For workloads needing strong consistency across many clients, this means object storage suits write-once, read-many or fully-replace patterns, while shared mutable state across clients needs either NFS with explicit locking or, better, an external coordinator or a database that provides transactions.

COMMON WRONG ANSWERS Believing object storage still has eventual consistency and adding workarounds no longer needed. Assuming you can safely do concurrent in-place edits or appends to one object as if it were a file. Treating NFS close-to-open as full linearizability for concurrent writers. Ignoring that neither offers transactional multi-object atomicity.

LIKELY FOLLOW-UPS What does close-to-open consistency actually guarantee. How do you coordinate concurrent writers on object storage, for example with conditional writes or a lock service. When do you reach for a database instead. How do conditional PUTs or ETags help avoid lost updates.

ONE CONCRETE EXAMPLE Two services must update a shared counter. On object storage, both read the object, increment, and PUT, and the second silently overwrites the first, a lost update, because there is no in-place mutation or lock. The fix is a conditional write keyed on the object's ETag so the second write fails and retries, or moving the counter to a database with atomic increments. On NFS, the same shared file needs an advisory lock to serialize writers, illustrating why neither replaces a transactional store for contended mutable state.