Cloud Spanner Architecture: Global Scale and Strong Consistency

Cloud Spanner is a fully managed, globally distributed database service from Google Cloud. It combines the benefits of a traditional relational database (like the ones that power bank accounts or inventory systems) with the ability to scale out across many servers and many geographic regions. To understand why this matters, you need to know a few fundamental concepts.

First, a database is a place where an application stores structured data — think of it like a giant, organised spreadsheet with rows and columns. A relational database uses strict rules (schemas) to ensure data integrity, meaning the data is always correct and consistent. For decades, most relational databases were single-server: one machine stored all the data. That was fine for small businesses, but a global online shop serving customers in dozens of countries would face huge problems: the single server would be too slow, and if it broke, the entire shop would go offline.

To solve these problems, engineers built distributed databases. A distributed database spreads data across many servers (horizontal scaling) and often across multiple data centres. But distributing data introduces a classic conflict: the CAP theorem. CAP stands for Consistency (everyone sees the same data at the same time), Availability (the database stays up even if some servers fail), and Partition Tolerance (the system keeps working even if network connections between servers are cut). The theorem says you can only have two out of three. Most distributed databases sacrifice strong consistency to keep availability and partition tolerance. They use a model called eventual consistency, meaning updates take time to spread — during that time, different users might see different versions of the same data. For a bank transfer or a flight booking system, eventual consistency is unacceptable. If you check your balance and see $100, then your partner sees the same $100 and both of you withdraw $100, the bank could lose money.

Cloud Spanner breaks the CAP trade-off by using Google’s global network and a technology called TrueTime. TrueTime is a service that gives every Spanner server a very accurate, synchronised clock using GPS and atomic clocks in Google’s data centres. This synchronised clock allows Spanner to order all writes (data changes) globally with extremely high precision. When a write happens, Spanner assigns it a timestamp. To read data, Spanner uses the timestamps to ensure that every read sees the most recent write — even if the reader is in a different region. This is why Spanner offers strong consistency across the entire globe. Strong consistency means that once a write is acknowledged, any subsequent read from any location will see that write, as if there were only one copy of the data.

How does horizontal scaling work in Spanner? Instead of one server, Spanner splits data into small units called splits. Each split is a range of rows. Spanner automatically distributes these splits across thousands of servers in many regions. If a region experiences a spike in traffic, Spanner can split a hot split into smaller ones or move splits to less loaded servers. This all happens without downtime. You don’t need to manually add more servers — Spanner just uses more of Google Cloud’s infrastructure as needed.

For global distribution, Spanner uses a concept called multi-region configurations. A multi-region configuration is a set of geographic regions where Spanner keeps copies of your data. For example, you can configure a Spanner instance to have replicas in London, Frankfurt, and Zurich. Each replica stores a full copy of the data. Writes are replicated synchronously across the replicas before being acknowledged to the user. This means a write is only considered successful when all replicas in the configuration have it. That’s why strong consistency is possible: every copy is always up to date. However, this also adds latency because the write must travel across continents before it’s confirmed. To reduce latency for reads, Spanner supports read-only replicas that can serve reads from a nearby copy without waiting for the full write confirmation.

The key benefits are:

In summary, Cloud Spanner is a relational database that behaves like a single machine for consistency but scales like a web-scale distributed system. It replaces the need to build complex custom database infrastructure that tries to keep multiple copies in sync, which is error-prone and expensive to maintain. For the PCDE exam, you need to understand that Spanner’s architecture is built around synchronised clocks, automatic splitting, and synchronous replication to deliver strong consistency at a global scale.

As a database engineer working for a fast-growing e-commerce company, you are responsible for the product catalogue service. The company has offices in London, New York, Tokyo, and Sydney, and customers worldwide expect to see the same prices, stock levels, and product details no matter which region they connect to. Previously, the company used a single database in London with read replicas in other regions. The problem was that when a price changed in London, customers in Tokyo might see the old price for up to five minutes, leading to incorrect orders and support tickets. The business cannot afford that.

You decide to migrate the product catalogue to Cloud Spanner. Here is what you do step by step:

1. You go to the Google Cloud Console and create a new Spanner instance. You choose a multi-region configuration called nam3 that spans three regions in the United States: us-central1 (Iowa), us-east1 (South Carolina), and us-west1 (Oregon). For your global use case, however, you would pick a configuration like global which includes replicas in North America, Europe, and Asia. You configure the number of read-write replicas (regions that can serve both reads and writes) and read-only replicas (regions that only serve reads, which are cheaper and faster for reading but cannot handle writes).

2. You define the database schema. The catalogue has a table called Products with columns like ProductID, Name, Description, Price, StockQuantity. You define a primary key on ProductID. Spanner uses the primary key to distribute rows across splits. You also choose an interleaved table for product reviews: each review row belongs to exactly one product, and they are stored together physically so queries for a product and its reviews are very fast.

3. You write a script to export the existing product data from the old database and import it into Spanner using the Dataflow service (a managed data processing tool). The migration runs overnight with a short maintenance window.

4. After the migration, you update the application’s connection string to point to the Spanner instance. Because Spanner offers strong consistency, you can remove all the custom code that previously tried to handle eventual consistency — for example, polling multiple replicas and comparing timestamps. The application code becomes simpler and less error-prone.

5. You monitor the system using Cloud Monitoring (formerly Stackdriver). You set up alerts for high read latency or write latency. You notice that during a flash sale in Tokyo, the Spanner instance’s split serving the most popular products becomes a hot spot (a split receiving many requests). You learn about Spanner’s automatic split management: it will eventually split the hot split into smaller ones, but you can also use a command to manually split a range of rows to distribute the load more evenly. You decide to let the automatic process handle it for now.

As an IT professional, your day-to-day tasks involve:

The main productivity gain is that you no longer need to manage database replication, failover, or conflict resolution. Spanner handles all that under the hood. You focus on the data model and query performance, not on infrastructure.