I missed a really important point in these slides that I'll add before Mexico City about journaling and what it is. Basically, when you do a write to high replication datastore, the write "succeeds" and the API call returns once your write has been inserted into the journals of a majority of data centers/datastore instances. A journal is like a todo list of writes you need to do. It's similar to MySQL's binary log, though that's not how replication works in HRD. For instance, suppose you are updating an entity. That update goes into a journal and not directly into the datastore. When the datastore gets around to applying the journal - that is, doing the actual entity update as well as any secondary entities that need updating (indexes, composite indexes), this is when the "version" of the data is updated.

In slide 30/34, when I say "catch up the datastore", what this means is "block until the local datastore instance has applied all writes up to the newest version we expect to have". The reason this isn't slower is because if a catch up operation is required, we also send RPCs to remote datastore instances and return to the user the first data that's returned to us.﻿