@Jason No, no design doc yet. I mean to do one when I can get a suitable block of time for this.
ZAB is not necessary for basic read replicas that sync "eventually", basic MySQL-like master-slave. That would be the first step of course since most would only need that. Initial thoughts on this is a region slave can get notice from the region owner via zk that a log has rolled and process the new edits from there. Slaves will be under different memory pressure for their mix of regions than the owner, is the only significant detail to work through I think. So for this possibly shadow/temporary flush file storage for slaves that are managing shadow memstores, while sharing the permanent store files with the owner. Also need some zk-mediated coordination around splitting and compaction. Preferably the owner can do splits and compactions leaving the shared store files alone to the last possible moment, then do a change notification via zk and a HDFS rename. And, when all slaves have stopped sharing old storefiles, then garbage collection.
ZAB would be for a next step, getting cliques to all see and agree upon edits coming in, in effect master-master-master replication. This is blue sky stuff. Regions would have higher availability than single region server hosting, yet all clients would have a consistent view of the data contained therein at any moment. However a region would need be deployed to 2N+1 regionservers, where N is the number of expected concurrent node failures, or it would not be writable as long as lacking quorum.