What is eventual consistency in object stores?

All data storage has three factors referred to as CAP: consistency, availability and partitioning. Most users want to stay away from partitioning because if affects consistency and availability. When you have to scale out storage, you have to deal with these issues. But object stores have eventual consistency -- and not immediate consistency -- on the read.

Let’s say you've just changed an object by writing to it, but someone else is now accessing that object on a different node. The node could be in a different physical location because object storage can scale across a large geographic region. This new user will be reading the object, but it will be an older version. And while there will be eventual consistency of the object stores, it's not consistent at that moment in time.

That's a problem for a lot of people, especially if you use an object store for collaboration. Some vendors have done a good job of providing guaranteed consistency for their object storage, such as Joyent with its Manta Storage Service, and don't allow you to read the old content once it has been changed. You have to wait to read the content, but what you read is consistent. In addition, everybody does things a little differently on the consistency front.