Library / Papers
Availability in Globally Distributed Storage Systems at Google
A real-world engineering write-up from Google on availability in Globally Distributed Storage Systems at Google.
By Google · Google · Added 2026-10-12
All content belongs to Google. We only link to it and give credit. Report a problem
Learn this paper
About 37 min left. Your work is saved as you go.
What you are about to study
Google wrote this paper. Read the abstract and headings first. You should know the basics: caching, queues and replication.
Ideas you will meet
- Distributed Systems
- Consensus, time, failure and the fundamentals of scale-out.
What we already know about this
Our own lessons on these ideas. Read them here before you start, so it makes sense.
Advanced Distributed Systems · 12 minRedis: persistence, replication, Sentinel and ClusterWhat keeps an in-memory database from losing data and from being a single point of failure: snapshots, the append-only file, replicas, Sentinel and hash slots.Read here
Fast because it is in memory, durable because of logs
Redis keeps its dataset in RAM (the reason it is so fast; see the Redis and Memcached lesson). To survive a restart it offers two persistence mechanisms, which can be combined.
Snapshots (RDB)
Redis periodically writes a point-in-time snapshot of the whole dataset to disk, using a forked child process so the main process keeps serving. Snapshots are compact and quick to load, but anything written since the last snapshot is lost on a crash.
Append-only file (AOF)
Redis appends every write command to a log. On restart it replays the log. The fsync policy sets the loss window:
Policy Behaviour Risk alwaysFlush after every command Slowest, almost no loss everysecFlush once per second At most about a second lost (common default) noLet the OS decide Fastest, larger loss The AOF grows, so Redis periodically rewrites it into a compact form. Many deployments use AOF with
everysec, sometimes plus snapshots for fast backups.100%Figure SDA-ADS-04-1 · Redis persistence choices · © forcsguy.com
Replication and Sentinel
A Redis primary replicates to one or more replicas asynchronously. Replicas serve reads (possibly slightly stale) and can take over. Sentinel is a small set of monitor processes that:
- watch the primary and replicas,
- agree by quorum that the primary is down,
- promote a replica and tell clients where the new primary is.
100%Figure SDA-ADS-04-2 · Sentinel failover · © forcsguy.com
Because replication is asynchronous, a failover can lose the last few acknowledged writes. Redis offers settings to reduce this (for example requiring a minimum number of replicas to acknowledge), at the cost of availability.
Redis Cluster: sharding
When data or traffic outgrow one node, Redis Cluster shards the keyspace into 16,384 hash slots. A key's slot is a hash of the key modulo that number; each node owns a range of slots, and each primary has replicas. Clients learn the slot map and talk to the right node; a wrong guess gets a redirect.
- Resharding moves slots (and their keys) between nodes while the cluster runs.
- Multi-key operations only work when all keys are in the same slot. Hash tags (a
{tag}part of the key) force related keys into one slot. - Failover is built in: replicas of a failed primary are promoted by the cluster.
- This is the "fixed number of slots" cousin of consistent hashing (see the consistent-hashing lesson).
Which setup when
Need Choice Pure cache, loss acceptable Single node or replicas, little or no persistence Must survive restart AOF (everysec) and snapshots Must survive node loss Replica plus Sentinel Data larger than one node, or very high throughput Redis Cluster Also keep memory in mind: set a max memory and an eviction policy (see the caching lessons) so Redis behaves predictably when full, and watch for large keys and slow commands, which block a single-threaded executor.
Real-world reading
Related reading
- Redis DocumentationRedis · Redis Ltd.Documentation
- Redis persistenceRedis · Redis Ltd.Documentation
- Redis UniversityRedis · Redis Ltd.Courses
- Redis BlogRedis engineers · Redis Ltd.Blogs
Show 6 moreShow fewer
- Scale with Redis ClusterRedis · Redis Ltd.Documentation
- RedisRedis · Redis Ltd.GitHub
- Failover with Redis Sentinel at VintedVinted engineers · VintedCase Studies
- Memory Optimization in Redis at WattpadWattpad engineers · WattpadCase Studies
- Speeding Up Redis with Compression at DoorDashDoorDash engineers · DoorDashCase Studies
- Availability in Globally Distributed Storage Systems at GoogleGooglePapers
Go deeper on this
A path through videos, articles, other case studies and code on the same ideas as Availability in Globally Distributed Storage Systems at Google.
Warm upGet the vocabulary first.
Books · Free from the author
Concurrent and Distributed Systems (Cambridge lecture notes)
Eight lectures on time, broadcast, replication, consensus and transactions, with notes, slides and video. Free from the author under CC BY-SA.
University of CambridgeIntermediate
Books · Free from the author
Computer Networks: A Systems Approach
How networks are built and why: protocols, routing, congestion control and the internet's architecture. The authors publish it free online under CC BY 4.0.
Systems ApproachIntermediate
WatchHow others solve the same problem, on video.
Videos belong to their creators and play from YouTube. More on YouTube (opens in a new tab)
ReadEngineers explain it in their own words.
Blogs · Free from the author · Read here
Scalable Web Architecture and Distributed Systems
A full chapter on the building blocks of large websites: availability, performance, reliability, scalability, caches, proxies, indexes, load balancers and queues. Free to read here under CC BY 3.0.
The Architecture of Open Source ApplicationsBeginner40 min
Papers · Read here
Facebook’s photo storage
This paper describes Haystack, an object storage system optimized for Facebook’s Photos application. Facebook currently stores over 260 billion images, which translates to over 20 petabytes of data.
USENIXIntermediate
See it in another companyThe same ideas, a different system.
Case Studies · Read here
Aroma: Using ML for Code Recommendation at Facebook
Thousands of engineers write the code to create our apps, which serve billions of people worldwide. This is no trivial task—our services have grown so diverse and complex that the codebase contains…
FacebookIntermediate
Case Studies · Read here
Brooklin: Distributed Service for Near Real-Time Data Streaming at LinkedIn
Brooklin—a distributed service for streaming data in near real-time and at scale—has been running in production at LinkedIn since 2016, powering thousands of data streams and over 2 trillion messages per day. Today, w...
LinkedInIntermediate
Read the codeSee how it looks when it is real.
GitHub
Engineering Blogs
A huge directory of company engineering blogs to learn from real production systems.
kilimchoiIntermediate
GitHub
Awesome Scalability
Curated reading list of articles on the architecture of scalable, reliable systems.
binhnguyennusIntermediate
Keep learning
Loading community…