# Apache HBase for system design interviews > Apache HBase is a distributed wide-column database built for large datasets with frequent writes, key-based reads, and ordered range scans. It fits designs where access patterns can be expressed through row keys and column families, but it does not provide general SQL queries or transactions across arbitrary rows. Source: https://sysround.com/tech/hbase Updated: 2026-11-05 ## How it works An HBase table is a sparse, sorted map. A cell is identified by a row key, column family, column qualifier, and timestamp, allowing multiple versions of a value. Column families are declared in the schema, while qualifiers can vary between rows. Wide-column does not mean an analytical columnar format like Parquet. Tables are divided into regions covering contiguous row-key ranges. RegionServers serve these regions, and clients cache region locations discovered through the hbase:meta catalog. Reads and writes normally go directly to RegionServers. HMaster manages assignments, balancing, and administrative work rather than proxying every request. With normal durable writes, the RegionServer records mutations in a write-ahead log and updates an in-memory MemStore. Each column family within a region has its own store. MemStores flush into immutable HFiles, normally on HDFS, and background compactions merge files and reclaim eligible obsolete versions and deleted data. Reads combine visible data from MemStores and HFiles. Block caches reduce storage reads, and Bloom filters help skip files that cannot contain a requested key. Many files, cache misses, and compaction pressure can increase read latency, so fast writes do not eliminate storage maintenance costs. HBase provides atomic mutations within one row and strongly consistent reads from the primary region replica. A scan across many rows is not a table-wide snapshot. Optional timeline-consistent reads from secondary region replicas can return stale data. ## What it gives you in a design - **Ordered key access.** Point reads and scans over contiguous row-key ranges are native operations. Put frequently queried dimensions into the key, since filtering unrelated columns is not a substitute for an index. - **Sparse, flexible columns.** Rows can contain different qualifiers without storing every possible column. Keep the number of column families small because each family adds storage and flush-management overhead. - **Row-level conditional updates.** Conditional mutations and atomic row operations support compare-and-set workflows and counters. They do not extend into a transaction across multiple rows. - **Cell versions and expiration.** Timestamped cell versions and column-family TTL support retained history and expiring data. Version retention must be configured explicitly, and expiration does not imply immediate physical deletion. - **Bulk loading.** Prepared HFiles can be bulk-loaded for large imports instead of sending every cell through the normal mutation path. The import still needs a plan for key distribution and concurrent changes. - **Cluster-to-cluster replication.** WAL-based replication can copy edits asynchronously to another cluster. It supports disaster recovery and remote copies, but does not provide globally synchronous commits or cross-cluster serializability. ## Scaling, replication and failure HBase partitions by ordered row-key ranges, not consistent hashing. Regions split as data grows and can move between RegionServers. Pre-splitting helps distribute initial load, but only if incoming keys actually span the split ranges. Row-key design determines write distribution. A leading increasing timestamp can direct new writes to one region, while a tenant or device prefix can isolate useful scans but concentrate a large customer's traffic. Salting or bucketing spreads writes at the cost of parallel scans and result merging. HDFS normally replicates the underlying files, while one primary region replica serves strongly consistent access for each region. Optional secondary region replicas serve timeline-consistent reads. After a RegionServer failure, region reassignment and recovery of durable WAL edits cause a period of reduced availability. Adding RegionServers helps when load is spread across many regions; it does not make one hot row arbitrarily scalable. Cross-cluster replication is asynchronous, so a regional failover can lose access to recent edits that have not reached the destination. State the recovery-point objective and how writers are fenced during failover. ## Limits and defaults worth knowing - **Maximum row-key length:** A row key can be at most 32,767 bytes. Much shorter keys are usually preferable because keys contribute to storage and I/O overhead. - **Default client cell-size check:** The hbase.client.keyvalue.maxsize setting defaults to 10 MiB for a serialized KeyValue. It is configurable; this default is not a recommendation to store large objects in cells. - **Default version retention:** Column families retain one cell version by default. The maximum version count is configurable. - **Default TTL:** Column-family TTL defaults to FOREVER. A configured TTL is expressed in seconds; expired data is generally reclaimed during compaction. - **Atomicity boundary:** HBase provides row-level atomic mutations, not general multi-row transactions. A batch of mutations across rows is not an all-or-nothing transaction. ## Use it when - The dataset is large, write-heavy, and accessed mainly by exact keys or bounded key-range scans. - Metrics, trace records, or event histories can be organized around a stable entity-and-time key. - Sparse records or retained cell versions are useful, and general relational queries are not required. - Single-row conditional updates satisfy the correctness requirements, and the team can operate an HBase storage stack. ## Avoid it when - The core workflow needs joins, foreign keys, or atomic transactions across many independent records. - Users need ad hoc filtering and aggregation across arbitrary fields without maintaining additional indexes or analytical systems. - The dataset and traffic fit comfortably in a simpler relational database or managed key-value service. - Most traffic targets one row, or the requirement is synchronous, strongly consistent writes across multiple regions. ## What interviewers ask about it ### How would you choose a row key for time-series data? Start with the required scan, such as readings for one device over a bounded time interval, and consider a device-plus-time key. Check whether a busy device or sequential prefix creates a hotspot; adding buckets spreads traffic but makes reads fan out. ### What happens when a RegionServer crashes? The cluster detects the failure, reassigns its regions, and recovers durable edits from WALs. Under normal synchronous WAL durability, acknowledged writes are intended to survive the failure, but affected regions can be unavailable during recovery. ### Is HBase strongly consistent? Normal reads from the primary region replica are strongly consistent, and mutations are atomic within a row. That does not imply multi-row serializability, a consistent snapshot for a table scan, or fresh reads from optional timeline-consistent replicas. ### How do you query by a field that is not in the row key? Maintain another table keyed by that field, or use a separate indexing system. Explain how index updates survive retries and partial failures, because updating the source row and a separate index row is not one native atomic transaction. ### Why can latency rise even after adding RegionServers? A hot row or narrow key range may still concentrate requests on one primary region replica. Compaction, excessive HFiles, cache misses, and underlying storage contention can also dominate latency, so inspect key distribution and storage pressure before adding nodes. ### How would you make retried writes safe? Use deterministic row keys and, where appropriate, explicit cell timestamps so replay targets the same logical data. A repeated increment is not inherently idempotent; use request identifiers and row-level conditional mutations when duplicate application would be incorrect. ## Common mistakes - Using a monotonically increasing timestamp as the leading row-key component without addressing concentrated writes. - Assuming a sparse wide-column schema provides efficient queries on every column. - Treating HDFS replication, secondary region replicas, and cross-cluster replication as interchangeable consistency and availability mechanisms. - Assuming a batch is a multi-row transaction or that TTL immediately erases bytes from storage. ## Alternatives - **Apache Cassandra:** Prefer it when decentralized operation, multi-datacenter writes, and tunable consistency fit the requirements better than HBase's primary-region serving model and ordered row-key ranges. - **Google Cloud Bigtable:** Prefer it when a managed wide-column service fits the deployment environment and reducing cluster operations matters more than controlling an Apache HBase installation. - **PostgreSQL:** Prefer it when relational queries, secondary indexes, and multi-row transactions are central, especially when scale does not justify a specialized distributed store. - **ClickHouse:** Prefer it when the main workload is analytical aggregation over many records rather than mutable, row-key-oriented serving. ## Interview questions where it comes up - [Design a metrics monitoring system like Datadog](https://sysround.com/questions/design-metrics-monitoring-system): HBase can store device- or metric-keyed time series, making row-key distribution, cardinality, TTL, and scan boundaries important design decisions. - [Design a distributed tracing system](https://sysround.com/questions/design-distributed-tracing): Trace records can be stored by trace identifier, while search by service, time, or tags requires a separate indexing strategy. - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): HBase provides a concrete reference for range partitioning, WAL recovery, row-level consistency, and storage-backed replication. - [Design Google Analytics](https://sysround.com/questions/design-google-analytics): HBase can serve precomputed aggregates and entity histories when the design addresses hot tenants, retry-safe updates, and access-specific keys. ## FAQ ### What is Apache HBase used for? Apache HBase stores large sparse datasets that need frequent writes, key lookups, or ordered range scans. Examples include device histories, metrics storage, and entity-keyed event records. Its suitability depends heavily on whether the row-key layout matches the queries. ### What is the difference between HBase and HDFS? HDFS is a distributed file system, while HBase is a database that normally uses HDFS for durable files and logs. HBase adds row-level reads and writes, sorted regions, caching, versioned cells, and database recovery behavior. ### Is HBase SQL or NoSQL? HBase is a NoSQL wide-column database with APIs for key-based reads, mutations, and scans rather than a native general-purpose SQL interface. Apache Phoenix can provide a SQL layer over HBase, but that does not remove row-key design constraints or make arbitrary queries inexpensive. ## Related concepts - [LSM trees](https://sysround.com/concepts/lsm-tree) - [Write-ahead log](https://sysround.com/concepts/write-ahead-log) - [Partitioning strategies](https://sysround.com/concepts/data-partitioning) - [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys) - [Database replication](https://sysround.com/concepts/replication) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.