A post from Cursor about Continuity, the Git storage system they built to host repositories at real scale. Instead of treating each repo as one precious copy on one disk, every push goes to a write ahead log in S3 first, and the client only hears back once that write is durable. Local disks become warm caches that can be rebuilt at any time, and replicas stay in sync with gossip over UDP plus conditional reads against S3. The post also covers repacking without making every replica redo the same expensive work, and gives real numbers: about 120 pushes a second on standard S3 and over 300 on S3 Express One Zone.
An overview of rendezvous hashing, a simple way to assign objects to servers without a central coordinator. Each server gets a score from the object and server names, and the highest score wins. Every client reaches the same result, and adding or removing a server moves only the objects affected by that change. The article also compares the method with consistent hashing and covers replication, weights, and faster variants.
A paper from Amazon engineers on how Aurora DSQL works inside. DSQL is a serverless SQL database that runs active active across regions, so any region can take reads and writes at once. The design splits the two apart: reads use multiversion concurrency control with precise timestamps and never coordinate with other nodes, while writes use optimistic concurrency control and coordinate only at commit time, through components called adjudicators and a replication layer called the Journal. Query processors run in small Firecracker microVMs and keep no local state, which lets compute, storage, and coordination scale on their own, from idle up to millions of transactions per second. The paper shows how all of this keeps full ACID transactions even when an availability zone or a whole region fails.
A Cloudflare post about Meerkat, a consensus system they built to keep control plane state consistent across their 330 plus data centers. It runs on QuePaxa, an algorithm that needs no leader. In Raft a dead leader or a slow network stalls writes until a new one is elected, and the timeouts are hard to tune across the wide area internet. QuePaxa instead lets any replica propose a write at any time, and concurrent proposals help each other reach agreement rather than block each other. The post is honest about the cost, since each write still takes one to three round trips, so Meerkat suits data that changes rarely and must stay correct rather than a busy database. It is also the first time QuePaxa has run at production scale.
A USENIX ATC paper that looks back at how DynamoDB grew from the original Dynamo design into a managed service. It shares what the team learned from running the system at a very large scale and shows how distributed storage works in production, not just in theory.