For a number of applications, availability isn't something that can be sacrificed. However, in some cases, availability requirements for read operations might be different from availability requirements for write operations. There's a category of applications for which the database always needs to be available for reads. However, often these systems have a robust ingestion pipeline that can buffer writes. So, if certain regions are unavailable, the writes will simply backlog and resume once the regions come back online.

So, if the application can't tolerate read unavailability, can we reduce the duration of the downtime? HBase provides a feature called region replication. If this feature is turned on, each region in the table will have a set of replicas. One of the replicas is considered active, while the rest are standby replicas. Each RegionServer hosts some active region replicas and some standby replicas. Naturally, the active and standby of the same region will not be hosted in the same RegionServer. The client issues a read against the active replica and if that times out, it reissues the query against all of the standby replicas. This way, there's a higher probability that a query can be serviced. A detailed explanation of how replicated reads work is outside the scope of this chapter.

So, what do we lose out by gaining this high availability? This comes at the cost of consistency. The active and standby replicas are kept in sync via asynchronous replication, so it's possible that the active replica might reflect writes that might not have been processed by the standby replica yet. So, if the application wants higher availability and can accept a weaker consistency level, using replicated reads is a good option to explore.