# Google Bigtable for system design interviews > Google Bigtable is a managed wide-column database for large, sparse datasets accessed by row key or row-key range. It fits high-volume telemetry, time-series data, and serving workloads where you can design the keys around known queries and do not need transactions across rows. Source: https://sysround.com/tech/bigtable Updated: 2026-11-05 ## How it works A table is an ordered map of rows sorted lexicographically by row key. Each row contains column families, qualifiers within those families, and timestamped versions of each cell. Families are defined ahead of time, while qualifiers can be created dynamically, making sparse records natural. Bigtable divides contiguous row-key ranges into tablets and assigns tablets to serving nodes. It splits and redistributes tablets as data and traffic change. This is range partitioning, not consistent hashing, so neighboring keys stay together and the leading bytes of your row key strongly affect load distribution. The storage engine uses an LSM-style write path: writes enter a durable log and an in-memory structure, then flush into immutable SSTables. Reads combine relevant in-memory and on-disk data, while background compaction merges files and removes eligible old versions. Bloom filters help avoid unnecessary file reads. Compute and storage are separated. Durable files live in Google's distributed storage system, Colossus, rather than depending on a serving node's local disk. Tablet reassignment can therefore recover service without copying the whole dataset to a replacement node, although failures and rebalancing can still affect latency. An instance can contain multiple clusters, with asynchronous replication between them. Application profiles control request routing and access to single-row transactional operations. Single-cluster access provides strong consistency; routing across replicated clusters generally introduces eventual consistency and requires an explicit failover policy. ## What it gives you in a design - **Ordered key and range access.** Point reads, prefix scans, and bounded row-key scans are core access patterns. Design keys from the queries first, since filtering a large scan does not turn it into an efficient indexed lookup. - **Sparse, versioned cells.** Rows can have different qualifiers, and cells can retain multiple timestamped versions. This works well for sparse attributes and time-oriented data, but version retention must be deliberate. - **Single-row atomic operations.** Mutations within one row are atomic, and conditional mutations support compare-and-set-style updates. There is no general transaction spanning multiple rows or tables, and transactional operations require a compatible application profile. - **Column-family garbage collection.** Retention policies can remove versions by age, version count, or combinations of those rules. Collection is asynchronous, so use read filters when an application must immediately exclude expired versions. - **Managed scaling and replication.** Bigtable manages tablet placement and supports autoscaling for supported cluster configurations. Replicated clusters provide regional placement and failover options, but more nodes or replicas do not fix a single hot row. - **Change streams.** Change streams expose data changes for downstream processing, replication pipelines, and materialized views. Consumers still need checkpointing, retry handling, and idempotent processing rather than assuming exactly-once external effects. ## Scaling, replication and failure Spread writes across key ranges that can become independent tablets. A timestamp-first key concentrates new writes at one end of the table; an entity-first key such as device_id#time_bucket#timestamp can distribute traffic when many devices are active. A very busy entity may still need a shard prefix, which makes reads fan out across shards. Tablets split and move automatically, but a row is not split across nodes. Increasing node count helps only when enough independently busy key ranges exist. Plan capacity using representative reads, writes, row sizes, and scans, and leave headroom for failures and rebalancing rather than quoting a universal throughput-per-node number. Requests served by one cluster are strongly consistent. Replication between clusters is asynchronous, so multi-cluster routing can return stale data, including after a write succeeds elsewhere. Route related reads and writes to the same cluster when read-your-writes matters, and explain how failover may temporarily weaken that guarantee. Concurrent updates to the same cell in different clusters are resolved using timestamp-based conflict resolution, not application-level merging. Avoid using independent regional writes for inventory, balances, or other invariants that require coordination. Retry transient errors with backoff, and distinguish retry-safe mutations from operations such as increments whose outcome may be uncertain after a timeout. ## Limits and defaults worth knowing - **Row-key size:** Maximum row-key length is 4 KiB. Keep keys much smaller when possible because they add storage and processing overhead. - **Cell value size:** Maximum cell value size is 100 MiB. Google's schema guidance recommends keeping values below 10 MiB. - **Row size:** Maximum row size is 256 MiB. Google's schema guidance recommends keeping rows below 100 MiB. - **Transaction scope:** Atomicity is scoped to a single row, not an entire batch of rows. Single-row transactional operations require a compatible application profile. - **Change-stream retention:** Change-stream retention is configurable from 1 to 7 days. Consumers that fall behind the retained window need another recovery source. ## Use it when - The workload has high write volume and predictable point reads or bounded scans over a very large dataset. - You can explain a row-key design that distributes load while preserving the locality needed by important queries. - Telemetry, event history, or precomputed aggregates need a serving database rather than a warehouse query engine. - Sparse records and per-cell versions are useful, and correctness can be handled within one row or by upstream processing. - Managed regional replication is valuable, and the design can state which operations tolerate stale reads. ## Avoid it when - Correctness depends on atomic transactions across accounts, seats, orders, or other independently keyed records. - The primary workload is ad hoc joins, large analytical aggregations, or exploration across arbitrary fields. - Most traffic targets one indivisible row, and the application cannot shard that state or absorb reads with caching. - The dataset is modest and a relational database would provide simpler queries, constraints, and operations. ## What interviewers ask about it ### How would you design a row key for device telemetry? Start with the reads: retrieving one device's recent measurements suggests device_id#time_bucket#timestamp. Check whether a few devices dominate writes, and add a shard component only if needed, since it turns one range scan into multiple scans that must be merged. ### Why does adding nodes not solve every hotspot? Bigtable distributes tablets, but an individual row cannot be split across nodes. A single hot row needs an application change such as sharded counters, time buckets, caching, or reduced update frequency. ### Can a client read its own write after regional failover? Not necessarily, because the destination cluster may not have received that write yet. Single-cluster routing provides strong consistency during normal operation, but the failover policy must explicitly address replication lag and acceptable stale reads. ### How do you make retried writes safe? Prefer deterministic row keys and repeatable cell assignments, using explicit timestamps when version identity matters. Increments and other non-idempotent operations need extra care because a timeout can occur after the server committed the operation. ### Can Bigtable enforce a uniqueness constraint across rows? It has no general cross-row uniqueness constraint or multi-row transaction. You can sometimes place the contested claim in one row and use a conditional mutation, but any dependent updates to other rows require a separate consistency and recovery plan. ### Does a retention policy make expired data immediately invisible? No, garbage collection runs asynchronously and is not an exact deletion deadline. Apply read-time timestamp or version filters for query correctness, and treat physical deletion timing as a separate operational concern. ## Common mistakes - Using a timestamp as the leading row-key component for a heavy append workload, concentrating writes on the newest key range. - Calling Bigtable an analytical columnar database because it uses column families; its primary access model is keyed rows and ranges. - Assuming replication provides globally strong consistency or that regional failover preserves read-your-writes automatically. - Treating multi-row write batches as transactions, or retrying increments as though they were idempotent assignments. ## Alternatives - **Apache Cassandra:** It fits similar wide-column workloads when partition-key-based distribution, deployment portability, or Cassandra's configurable consistency model is more important than Bigtable's managed range-partitioned service. - **Amazon DynamoDB:** It fits AWS-native key-value workloads where partition-key access, secondary indexes, and bounded transactional operations match the requirements better than ordered Bigtable row ranges. - **Google Spanner:** It wins when relational queries, secondary indexes, and strongly consistent transactions across rows are central to correctness. - **Google BigQuery:** It wins for warehouse analytics, broad scans, joins, and ad hoc aggregation rather than request-path keyed serving. ## Interview questions where it comes up - [Design a metrics monitoring system like Datadog](https://sysround.com/questions/design-metrics-monitoring-system): Bigtable can store time-bucketed metrics and rollups when row keys control cardinality, distribute ingestion, and bound dashboard reads. - [Design Google Analytics](https://sysround.com/questions/design-google-analytics): It can serve precomputed tenant and time-window aggregates while stream processing handles deduplication and late events. - [Design a distributed tracing system](https://sysround.com/questions/design-distributed-tracing): Trace-ID-keyed span storage fits Bigtable, while attribute-based trace discovery requires a separate index or serving view. - [Design an ad click aggregator](https://sysround.com/questions/design-ad-click-aggregator): It can hold sharded window aggregates, provided the design handles replay safety and does not treat stored counters as a transactional billing ledger. - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Bigtable provides a concrete example of range partitioning, LSM-based storage, single-row atomicity, and asynchronous cross-cluster replication. ## FAQ ### What is Google Bigtable used for? Google Bigtable stores large, sparse datasets that need high-volume writes and efficient key-based reads. Common fits include telemetry, time-series history, event data, and precomputed serving views. The deciding factor is whether the important queries map cleanly to row keys and bounded ranges. ### What is the difference between Bigtable and BigQuery? Bigtable is a serving database optimized around row keys and row-key ranges. BigQuery is an analytical warehouse designed for SQL queries over large datasets. A system can use Bigtable for application reads and BigQuery for historical analysis. ### Is Google Bigtable strongly consistent? Reads and writes served by one cluster are strongly consistent. Replication across clusters is asynchronous, so requests routed among clusters generally observe eventual consistency. State the routing policy and failover behavior rather than assigning one consistency label to every deployment. ## Related concepts - [Database sharding](https://sysround.com/concepts/database-sharding) - [LSM trees](https://sysround.com/concepts/lsm-tree) - [Hot keys and hot partitions](https://sysround.com/concepts/hot-keys) - [Database replication](https://sysround.com/concepts/replication) - [Time-series databases](https://sysround.com/concepts/time-series-databases) --- 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.