Question 1

What is Cloud Spanner?

Accepted Answer

Spanner is a globally distributed relational database that combines horizontal write scalability with strong external consistency and full SQL support, including schemas, secondary indexes and ACID transactions across rows, tables and regions. It is the only widely-available database that offers relational semantics and horizontal scaling simultaneously. The claim to explain rather than repeat is external consistency: transactions appear to occur in a global order consistent with real time, not merely serialisable. That is a stronger guarantee than most distributed databases offer and it is what TrueTime enables.

Question 2

What is TrueTime and why does Spanner need it?

Accepted Answer

TrueTime is Google's globally synchronised clock API backed by GPS receivers and atomic clocks in every data centre. It returns a time interval with a bounded uncertainty rather than a single instant. Spanner assigns commit timestamps and waits out that uncertainty before acknowledging a write, which is how it guarantees that any transaction starting later sees the earlier one — external consistency across regions. This is the deepest piece of Spanner theory an interviewer will ask, and the key insight is the commit-wait: Spanner deliberately waits a few milliseconds to make the ordering guarantee safe. It trades a small latency cost for a much stronger consistency model, and articulating that trade-off is the whole answer.

Question 3

How does Spanner scale, and what is a split?

Accepted Answer

Data is range-partitioned into splits based on the primary key, and splits are distributed across compute nodes. As data grows or a split becomes hot, Spanner divides it and rebalances automatically. Adding compute capacity increases throughput without any resharding work by you. The design consequence is the hotspot problem: because splits are ordered by primary key, a monotonically increasing key such as a timestamp or auto-increment ID sends every write to the last split, which cannot be parallelised. That single fact drives all Spanner schema design.

Question 4

How do you avoid hotspots in Spanner?

Accepted Answer

Do not use monotonically increasing primary keys. Use a UUID, hash the natural key, or bit-reverse a sequential ID so writes distribute across the key space. If you need time-ordered access, put a distributing component first in the key and the timestamp second, or shard the key with a computed modulus prefix. The specific advice for time-series in Spanner is a key like (shard_id, timestamp) where shard_id is derived from a hash — that spreads writes while keeping time-ordered scans within a shard. Interviewers ask this because it is the number-one cause of Spanner performing badly.

Question 5

What is an interleaved table in Spanner?

Accepted Answer

Interleaving physically co-locates child rows with their parent row in the same split, based on a primary key that begins with the parent's key. Reading a parent and its children then requires no distributed join, because the data is on the same server. It is the Spanner equivalent of designing for locality. The trade-off to name: the interleaved hierarchy is limited in depth, deleting a parent can cascade, and it makes the schema rigid because the parent key must prefix the child key. It is powerful for a strict one-to-many like Orders and OrderItems, and wrong for many-to-many relationships.

Question 6

What are Spanner configurations — regional, dual-region and multi-region?

Accepted Answer

A regional configuration keeps all replicas within one region, giving the lowest write latency and a 99.99% availability SLA. A multi-region configuration places replicas across regions with a designated leader region, giving a 99.999% SLA and local reads worldwide, at the cost of higher write latency because a quorum must span regions. The trade-off to state plainly: multi-region buys availability and global read locality, and pays for it in write latency, because a write must reach a quorum of replicas that are geographically distant. Choosing multi-region for a single-country application is a common and expensive mistake.

Question 7

How is Spanner priced and what is granular instance sizing?

Accepted Answer

You pay for compute capacity, historically in nodes and now in processing units where 1,000 processing units equal one node, plus storage per GB per month and network egress. Granular sizing lets you provision as little as 100 processing units, which made Spanner viable for smaller workloads that previously had to pay for a full node. The cost objection to Spanner used to be a substantial minimum monthly spend, and granular sizing plus autoscaling changed that materially. Knowing the current shape of the pricing is what stops you from ruling Spanner out on outdated assumptions.

Question 8

When is Spanner the right choice and when is it over-engineering?

Accepted Answer

It is right when you genuinely need horizontal write scaling with relational semantics, strong consistency across regions, or an availability SLA above what a single-primary database can offer. It is over-engineering when a single Cloud SQL or AlloyDB primary comfortably handles the load, because Spanner costs more and imposes real schema discipline around key design and interleaving. The honest answer is that most applications do not need Spanner, and saying so demonstrates judgement. The constraint to name is the write ceiling of a single primary — until you are near it, or need multi-region strong consistency, the added complexity is not justified.

Question 9

What is the difference between Spanner read-write and read-only transactions?

Accepted Answer

A read-write transaction takes locks, can read and write, and may be aborted and retried by the client library on contention. A read-only transaction takes no locks, cannot write, and reads a consistent snapshot at a chosen timestamp — so it never blocks writers and never gets aborted, making it much cheaper for reporting queries. The practical guidance is to use read-only transactions for anything that does not write, and stale reads with a bounded staleness when a few seconds of lag is acceptable, because they can be served by any replica rather than the leader. That routing decision is a major latency and cost lever.

Question 10

What is Firestore and how does it differ from Datastore mode?

Accepted Answer

Firestore is a serverless document database storing data as documents in collections, with real-time listeners, offline client support and strong consistency. Firestore in Native mode is the modern experience with real-time sync and mobile SDKs; Firestore in Datastore mode provides the older Datastore API semantics for existing applications, without real-time listeners. A database is created in one mode and cannot be switched. The irreversibility of the mode choice is the fact interviewers check. The rule to state: Native mode for anything new, especially mobile and web clients; Datastore mode only for compatibility with an existing Datastore application.

Question 11

How do you model data in Firestore, and what is the main constraint?

Accepted Answer

You model around your queries, because Firestore queries are shallow and index-driven: a query returns documents from one collection (or one collection group) and cannot join. You denormalise aggressively, duplicate data that is read together, and use subcollections for one-to-many. Every query must be backed by an index, and composite queries need explicitly-defined composite indexes. The performance property that justifies this discipline is that Firestore query latency depends on the size of the *result set*, not on the size of the collection — a query over a billion documents returning ten is as fast as one over a thousand. That is why modelling for the query is not merely a preference.

Question 12

How is Firestore priced and what is the usual cost surprise?

Accepted Answer

Firestore charges per document read, write and delete, plus stored data and network egress. The usual surprise is read volume: a listener on a large collection, an unbounded query, or a client that re-reads a list on every screen render can generate millions of reads. Costs scale with operations, not with data size. The mitigations to name are pagination with limits, caching in the client SDK, aggregation queries such as count() which are far cheaper than reading documents to count them, and maintaining counters rather than recomputing them. This is the number-one Firestore production issue.

Question 13

What are Firestore security rules?

Accepted Answer

Security rules are a declarative language evaluated on the server for every request from a client SDK, controlling read and write access based on the authenticated user, the document path, the document contents and the incoming data. They allow mobile and web clients to talk to the database directly without a backend, safely. The crucial caveat is that rules apply to client SDK access only — server SDKs using Admin credentials bypass them entirely. The other one is that rules are not filters: a query whose results could include documents the user cannot read is rejected outright, which confuses people expecting silent filtering.

Question 14

What are Firestore transactions and batched writes?

Accepted Answer

A transaction reads and writes atomically with automatic retry on contention, and is used when a write depends on the current value of a document. A batched write applies up to a limited number of writes atomically but performs no reads, and does not retry on contention because there is nothing to conflict on. The limit that shapes design is the sustained write rate on a single document — roughly one write per second — which means a global counter is an anti-pattern. Distributed counters with sharded documents are the standard workaround, and knowing that pattern is a strong signal.

Question 15

What is Cloud Bigtable?

Accepted Answer

Bigtable is a wide-column NoSQL database designed for very large volumes of key-value or time-series data with extremely low latency at high throughput. It has a single-index model — the row key — supports sparse columns organised into column families, and scales to petabytes with consistent single-digit millisecond reads. The framing to give is that it is the database behind Search, Maps and Gmail at Google, and that it is also the storage engine concept the HBase API is compatible with. The critical property is that it has *one* index: the row key. Everything else follows from that.

Question 16

How do you design a Bigtable row key?

Accepted Answer

Design it so that the reads you care about become contiguous range scans and the writes distribute evenly. Put the most selective, distributing field first, then time if you need time-ordered scans, using a reversed timestamp when you want newest-first. Avoid monotonically increasing prefixes such as a raw timestamp or a sequential ID, which create a hotspot on the last tablet. A good concrete example: for IoT, use deviceId#reversedTimestamp so all readings for a device are contiguous and writes spread across devices. Field promotion — moving a value from a column into the row key — is the standard technique, and being able to name it shows genuine Bigtable experience.

Question 17

What are the main limitations of Bigtable?

Accepted Answer

No secondary indexes, no joins, no multi-row transactions across arbitrary rows (single-row operations are atomic), no SQL in the traditional sense, and query patterns are limited to a point lookup or a row-key range scan. It also has a meaningful minimum cost because you provision nodes. These constraints are why the row key is everything: if you need to query by a second attribute, you either write a second table with a different key, or you scan. Recognising that duplicating data into a differently-keyed table is a normal Bigtable design, not a hack, is what an interviewer is testing.

Question 18

When would you choose Bigtable over BigQuery?

Accepted Answer

Bigtable for high-throughput operational access with millisecond point reads and continuous writes — IoT ingestion, personalisation lookups, financial tick data serving. BigQuery for analytical queries scanning large volumes with aggregations and joins. They are complementary: Bigtable serves the application, BigQuery answers the analytical questions, often over the same data exported or federated. The latency profile is the deciding factor: BigQuery query latency is on the order of a second even for trivial queries, which is fine for analytics and unacceptable for a request-path lookup. Framing it as latency-versus-scan rather than as OLTP-versus-OLAP is more precise.

Question 19

What is a Bigtable app profile and what is single-cluster versus multi-cluster routing?

Accepted Answer

An app profile defines how an application's requests are routed across the clusters in a Bigtable instance. Single-cluster routing sends all traffic to one cluster, which preserves read-your-writes consistency; multi-cluster routing automatically fails over between clusters for higher availability but gives only eventual consistency because replication is asynchronous. The trade-off is availability versus consistency, chosen per application rather than per instance — so a batch pipeline can use multi-cluster routing while a consistency-sensitive service uses single-cluster. That per-profile granularity is the useful detail.

Question 20

What is Memorystore and which engines does it support?

Accepted Answer

Memorystore is GCP's managed in-memory data store, supporting Redis, Valkey and Memcached. It handles provisioning, patching, monitoring and, on the standard tier, replication with automatic failover. It is used for caching, session storage, rate limiting, leaderboards and pub/sub within an application. The tier distinction matters: the basic tier is a single node with no replication, so a failure loses all cached data and any node restart is a cold cache. Standard tier adds a replica and automatic failover. Recommending basic tier for anything holding session state is a mistake interviewers watch for.

Question 21

What caching strategies would you use with Memorystore?

Accepted Answer

Cache-aside is the default: the application checks the cache, falls back to the database on a miss, and populates the cache. Write-through updates cache and database together for consistency at the cost of write latency. Write-behind buffers writes for throughput at the risk of loss. Choose TTLs that bound staleness, and add jitter so keys do not all expire simultaneously. The failure mode to name is the thundering herd or cache stampede when a hot key expires and many requests hit the database at once. Mitigations are TTL jitter, a single-flight lock so only one request repopulates, or proactive refresh before expiry — naming a mitigation is what makes the answer operational.

Question 22

What consistency model does Firestore provide?

Accepted Answer

Firestore provides strong consistency for document reads and for queries — a read after a successful write sees that write. Multi-document transactions are ACID. The client SDKs additionally provide a local cache with latency compensation, so a client sees its own write immediately even before the server acknowledges it. The latency-compensation behaviour surprises people during testing: the UI updates instantly, then the write can still fail server-side and be rolled back. Understanding that the local snapshot has a fromCache and hasPendingWrites flag is what separates someone who has built a Firestore app from someone who has read the docs.

Question 23

What is a collection group query in Firestore?

Accepted Answer

A collection group query searches across every subcollection with the same identifier regardless of its parent document — for example querying all "reviews" subcollections under every product at once. It requires a collection-group index to be defined explicitly. It relaxes the otherwise strict hierarchy of Firestore queries, which is what makes subcollection-based modelling viable. Without it, you would have to duplicate data into a top-level collection just to query across parents, so knowing it exists changes your data model.

Question 24

How do you export and back up Firestore?

Accepted Answer

Firestore supports managed export and import to Cloud Storage, either the whole database or specified collections, and scheduled exports can be automated with Cloud Scheduler. It also offers point-in-time recovery within a retention window on supported editions. Exports are billed as read operations. The billing detail is worth flagging: a full export of a very large database charges for reading every document, so daily full exports of a big database are expensive. Combining PITR for recent recovery with less frequent full exports for archival is the practical pattern.

Question 25

What is the difference between Firestore and Realtime Database?

Accepted Answer

Realtime Database is the older Firebase product storing one large JSON tree, with limited querying, region-locked instances and pricing based on bandwidth and storage. Firestore stores structured documents in collections, has richer indexed queries, better scaling characteristics, multi-region options and pricing based on operations. The remaining reason to choose Realtime Database is very high-frequency small updates such as presence or live cursors, where the operation-based pricing of Firestore becomes expensive. Naming that specific case shows you understand the pricing models rather than defaulting to the newer product.

Question 26

How does Bigtable replication work?

Accepted Answer

A Bigtable instance can have multiple clusters in different zones or regions, and data is replicated between them asynchronously and eventually consistently. Replication improves availability, allows isolating workloads — batch on one cluster, serving on another — and reduces read latency for geographically distributed users. Workload isolation is the underappreciated benefit: pointing a heavy MapReduce or Dataflow job at a separate cluster through its own app profile stops it from affecting serving latency. That is a design pattern interviewers like to hear because it solves a real problem elegantly.

Question 27

What is the Bigtable Key Visualizer?

Accepted Answer

Key Visualizer produces a heatmap of read and write activity across the row-key space over time, making hotspots immediately visible as bright vertical bands. It is the primary diagnostic tool for row-key design problems. It is the direct answer to "how would you prove that your row key is causing a hotspot?" — a much stronger response than reasoning about it abstractly. Naming a specific diagnostic tool is a reliable way to signal hands-on experience.

Question 28

What is Firestore's write limit per document and how do you work around it?

Accepted Answer

A single document supports roughly one sustained write per second; beyond that, contention causes failures and retries. The standard workaround is a distributed counter: shard the value across N documents, write to a random shard, and sum the shards when reading. This is the classic Firestore design question because the naive implementation — a single "likes" counter on a popular post — fails at exactly the moment the product becomes successful. The aggregation query count() has also reduced the need for some counter patterns, which is a useful modern addition.

Question 29

How would you choose between Firestore and Cloud SQL for a new application?

Accepted Answer

Firestore when the data is document-shaped, access patterns are known and simple, you want mobile and web clients to talk to the database directly with security rules, and you want serverless cost scaling from zero. Cloud SQL when you need ad-hoc relational queries, joins across entities, strong referential integrity, or an existing SQL-based reporting ecosystem. The decisive question to ask is whether the query patterns are known in advance. Firestore punishes unanticipated queries because it cannot join and every query needs an index; SQL absorbs them. Framing it that way is more useful than "NoSQL versus SQL".

Question 30

What is Spanner's PostgreSQL interface?

Accepted Answer

Spanner offers a PostgreSQL dialect alongside its native GoogleSQL dialect, supporting a subset of PostgreSQL syntax, types and the wire protocol, so existing PostgreSQL tooling and skills transfer. The dialect is chosen at database creation and cannot be changed afterwards. The purpose is portability and skills reuse rather than full compatibility — it is a subset, so you should verify the specific features you rely on. Knowing that the choice is permanent per database is the operational detail worth stating.

Question 31

What is Spanner change streams?

Accepted Answer

A change stream captures inserts, updates and deletes on selected tables or the whole database and makes them available to consumers, typically through a Dataflow connector, for replication into BigQuery, cache invalidation or event-driven processing. It gives change data capture natively rather than requiring trigger-based workarounds. The architectural value is decoupling: downstream systems learn about changes without polling the database or the application publishing events explicitly, which removes the dual-write consistency problem where a database write succeeds but the event publish fails.

Question 32

How do you decide between Bigtable and Spanner for a time-series workload?

Accepted Answer

Bigtable if the access pattern is key-and-range scans at very high write throughput with no need for transactions or secondary indexes — classic metrics and IoT. Spanner if you also need relational queries, joins with reference data, secondary indexes and multi-row transactions on the same data, and can accept higher cost per unit throughput. The practical tie-breaker is usually whether you need to query the time series by anything other than the key. If yes, Bigtable forces you to maintain duplicate tables, and at that point Spanner's indexes may be cheaper in engineering time even if more expensive in infrastructure.

Question 33

What is a Firestore index, and what is the exemption mechanism?

Accepted Answer

Firestore automatically maintains single-field indexes on every field, ascending and descending, plus array-contains indexes. Composite indexes for multi-field queries must be defined explicitly. Index exemptions let you disable automatic indexing on specific fields — important for large string or map fields that are never queried. Exemptions are a genuine cost and write-latency optimisation: every indexed field adds work to every write, so a document with a large unqueried payload field is paying for indexing it. Knowing exemptions exist is a strong signal of production Firestore use.

Question 34

What happens to a Spanner transaction under contention?

Accepted Answer

Spanner uses pessimistic locking for read-write transactions, so a conflicting transaction blocks and may eventually be aborted. The client library retries aborted transactions automatically, which means the transaction body must be idempotent and side-effect free, since it can run more than once. The requirement that the transaction body be safely re-runnable is the practical consequence that catches people — code that sends an email or increments an in-memory counter inside a transaction body will do it multiple times. Naming that is a good applied-knowledge signal.

Question 35

What is the difference between strong and eventual consistency, in the context of choosing a GCP database?

Accepted Answer

Strong consistency guarantees a read reflects all prior writes; eventual consistency allows a read to return stale data that converges over time. Spanner and Firestore give strong consistency; Bigtable with multi-cluster routing and Cloud SQL read replicas give eventual consistency for those read paths. The choice is a product decision about whether staleness is acceptable for a given read. The strongest way to answer is per read path, not per system: a bank balance must be strongly consistent, a "people also viewed" panel need not be. Interviewers ask this to see whether you apply consistency requirements selectively or treat it as a global setting.

Question 36

How would you migrate from Cloud SQL to Spanner?

Accepted Answer

Redesign the schema first for Spanner's key model — no sequential primary keys, interleaving where hierarchies exist, indexes chosen deliberately. Then move data with Dataflow or the Spanner migration tool, run dual writes or change data capture to keep both in sync, validate with reconciliation queries, cut reads over gradually, then cut writes and decommission. The point interviewers want is that it is not a lift and shift: an unchanged relational schema with auto-increment keys will perform badly on Spanner. Leading with schema redesign rather than data movement is the answer that shows you understand why.

Question 37

What is Firestore's aggregation query support?

Accepted Answer

Firestore supports count(), sum() and avg() aggregation queries that compute server-side and are billed at a small fraction of the cost of reading the matching documents. Previously the only way to count was to read every document or maintain a counter manually. It matters because "show the number of results" was historically one of the most expensive operations in Firestore. Knowing that aggregations exist and are cheap changes several design decisions, including whether you need a distributed counter at all.

Question 38

What is the role of Datastream, Dataflow and Pub/Sub around these databases?

Accepted Answer

Datastream provides change data capture from relational sources into BigQuery or Cloud Storage. Dataflow is the general-purpose processing engine used to move and transform data between Bigtable, Spanner, BigQuery and Pub/Sub with prebuilt templates. Pub/Sub carries events between services, and Spanner change streams and Firestore triggers publish database changes into it. The unifying idea to state is that operational databases serve the application and analytical stores serve analysis, with a streaming layer between them — never pointing dashboards directly at the production database. That architectural principle is what the question is really testing.

Question 39

How do you secure Bigtable and Spanner?

Accepted Answer

IAM roles at instance, database and, for Bigtable, table level; encryption at rest by default with optional CMEK; private connectivity via VPC Service Controls perimeters to prevent exfiltration; Data Access audit logs enabled for read and write visibility; and least-privilege service accounts per workload rather than shared credentials. The control that most distinguishes a serious answer is a VPC Service Controls perimeter, because both services are reached over Google APIs from anywhere on the internet with valid credentials — network controls alone do not contain them.

Question 40

Design the data layer for a global ride-hailing application. Which GCP databases and why?

Accepted Answer

Spanner for trips, payments and driver state, because it needs strong consistency, relational integrity and horizontal write scaling across regions. Bigtable for high-frequency location telemetry, keyed by driverId and reversed timestamp. Memorystore for driver availability, geospatial matching and rate limiting. Firestore for the mobile client experience where real-time listeners and offline support matter. Pub/Sub and Dataflow to stream everything into BigQuery for analytics, with change streams from Spanner so the warehouse stays current without dual writes. The closing scenario. What marks it senior is assigning each store to the property it uniquely provides — consistency, write throughput, latency, client sync — rather than picking one database for everything, and explicitly avoiding the dual-write problem by using change streams.

GCP Spanner, Firestore & Bigtable Interview Questions and Answers

How to use this set