How google solved a 22 year old challenge

Photo by Luke Jones on Unsplash

So now USA residents can update their gmail handle at most 3 times every year. Sooner it will be available for other region’s people as well hopefully

Now back in 2004 when gmail was created the gmail handle was treated as a primary key and it was designed to never change again

So later they decides to allow user to change gmail handle because many chooses unprofessional gmail handle in middle school and got stuck with it. But that was impossible

Why?

Google has bilions of user and so does gmail. So as gmail handle is identifier for gmail, drive, youtube and many more apps it’s present in billions in database rows as a primary key or foreign key. Gmail handle acts as a unique identifying number for all users. So if one user tries to update it all the databases in all the datacenter around the globe must reflect the new identifying number consistently which was physically impossible

But google solved it by making use of spanner ( Google’s distributed SQL database) and a atomic clock (more on this later)

How

Let’s understand what is an atomic clock is.A normal computer clock uses a quartz crystal. Quartz crystal vibrates 32,768 times/sec = 1 second

The problem is that quartz changes with:

• temperature
• humidity
• age
• voltage

so one server in Alaska can differ with another server in singapore with 18 milliseconds for example because of above factors

Atomic Clock

Instead of counting crystal vibration It counts atoms.

Usually Cesium-133.

A cesium atom naturally vibrates at exactly

9,192,631,770 cycles per second

That number is so stable that the SI definition of one second is based on it.

One second is literally defined as:

The duration of 9,192,631,770 transitions of the cesium-133 atom.

Atomic clocks are present in satelites and google uses them and for fault tolerance i mean if those fail google has local atomic clocks in data centers as well

Spanner

Atomic clocks are just to ensure the time that all data center agrees

Now imagine Data center A has some change in database (transaction) now if you can put timestamp with the transaction using that we can later identify order of change in database and replicate it across all database in all data center

But servers time may differ for example when someone is changing something in Datacenter A in similar time someone else could change same data in Datacenter B (replica) Although Datacenter A have commited first but because of time inconsistency Datacenter B could have earlier timestamp

This issue is solved by TrueTime which uses Atomic clock from satelite/local to return a small time interval using which data center decides we all passed a certein time

Suppose:

• Data Center A (Asia) updates your Gmail at 10:00:00.
• Data Center B (USA) may still think it’s 09:59:59.998 because clocks are never perfectly synchronized.

Without TrueTime, B might think the update hasn’t happened yet.

What Spanner does

1. A transaction is assigned a commit timestamp, for example 10:00:00.000.
2. Spanner does not immediately say “commit successful.”
3. It waits a few milliseconds until TrueTime guarantees every data center’s clock has passed 10:00:00.000. (server B also passed that time)
4. After that, the transaction is officially committed
5. Then if anything changes in B it will commited after that maintaining a true order or transaction

Note those difference in datacenter are always small so truetimer gives a small interval using atomic clocks so that all data center came to sync or cross a timeline

Replication

After a transaction is committed, the leader replica begins replicating the update to other data centers. Since data must travel over the network, this replication may take a short amount of time.

Now suppose another user reads the same data from a different data center before that update has arrived. Instead of returning stale data, Spanner checks via leader replica whether that replica has applied the latest required commit timestamp. If it hasn’t, Spanner waits briefly (or serves the request from an up-to-date replica, depending on the read type) until the required commit has been applied. This ensures that strongly consistent reads always return the latest committed data, even though replication is still in progress.

Note if any replica commit any transaction it notifies the leader

Aliases

Although using above technique the google team allowed to change emails but old emails can’t be just forgotten as many may have their old email in several places. Here comes aliases meaning when someone sends email to old address it just forward it to latest new email associated with that

And that’s how google is allowing it’s user to change their email handle. Thanks for reading

Before you go

• Please take a moment to like the post and follow the writer!
• Did you know that over 400,000 developers share what they’re building, learning, and discovering across our platforms every month? Learn how you can contribute here