Once one comes around to this point of view - it becomes clear that tolerating partitions within a data center is a non-goal. one should design for consistency and availability in a data center and only worry about partitioning at higher levels in the system (and only for applications/data-sets that are not ok with single data center service SLA). Imposing the overheads implied by partition tolerance on environments that do not have partitions is simply wrong.

to address your comments here: even though Cassandra is not Dynamo - it has much more in common with Dynamo than Big Table. In terms of CAP - it’s almost entirely Dynamo (except for the part about vector clocks and multiple versions). In it’s agreement with the architectural principles of Symmetry and Decentralization - it’s all Dynamo (except, as i noted, it’s starting to use Zookeeper).

i also didn’t talk about performance - because i wanted to focus on architecture. however when people talk glibly about reading from all replicas or about the whole vector timestamping thing (which involves reading all versions) - i would point out how expensive this type of stuff is likely to be. Cassandra has stuff stored in multiple files - and reading all versions in means much more expensive in terms of disk seeks.

@Taylor - i would be very interested in learning about Dynamo deployment at Amazon. I am pretty sure that Facebook’s Cassandra cluster is centralized. i am not sure about our exact memcache layout - but i do know that our requests to memcache cross core switches - and that core switch issues have caused some degree of isolation between web and memcache tiers in the past. so in that sense our memcache tier is ‘centralized’ and we had better ensure very good connectivity between these different tiers (which we try our best to do).