Why it matters
Write latency in HBase is dominated by WAL sync. Understanding why lets you make informed trade-offs between latency and durability. Getting these trade-offs right can 10x write throughput without sacrificing production requirements.
Write path knowledge also determines what data is at risk in various failure scenarios. Knowing which writes are lost in a RegionServer crash and which survive is important for application design.
The architecture
The client calls put with a row key, column, and value. The client's connection layer looks up the target region via cached meta and sends the put RPC to the corresponding RegionServer.
The RegionServer's write handler acquires a row lock, appends the mutation to the WAL, waits for the WAL sync policy to complete, and only then applies the mutation to the memstore for the target column family.
How it works end to end
The WAL sync is the durability boundary. Once the sync returns success, the mutation is durable in HDFS across multiple DataNodes. This is what allows the client to receive an acknowledgment. Even if the RegionServer immediately crashes, replay of the WAL on recovery reconstructs the mutation.
The memstore update is a simple sorted-map insertion. It is fast and happens after the durability boundary, so it does not directly affect write latency. However, if the memstore is full and needs to flush, the write may be delayed while flush completes.
Asynchronously, when the memstore reaches its flush threshold, the RegionServer flushes it to a new HFile. This is the point where data moves from RegionServer memory to HDFS as a permanent HFile. Reads can consult the new HFile immediately after flush.
Later still, compaction merges HFiles to bound their count. This does not directly affect writes but keeps read latency bounded and reclaims tombstoned space.