[{"title":"Git at any scale","url":"https://cursor.com/blog/git-at-any-scale","date":"2026-08-22","permalink":"https://polovko.me/pins/git-at-any-scale/","summary":"\u003cp>A post from Cursor about Continuity, the Git storage system they built to host\nrepositories at real scale. Instead of treating each repo as one precious copy\non one disk, every push goes to a write ahead log in S3 first, and the client\nonly hears back once that write is durable. Local disks become warm caches that\ncan be rebuilt at any time, and replicas stay in sync with gossip over UDP plus\nconditional reads against S3. The post also covers repacking without making\nevery replica redo the same expensive work, and gives real numbers: about 120\npushes a second on standard S3 and over 300 on S3 Express One Zone.\u003c/p>\n","tags":[{"name":"distributed-systems","url":"https://polovko.me/pin-tags/distributed-systems/"},{"name":"consensus","url":"https://polovko.me/pin-tags/consensus/"},{"name":"performance","url":"https://polovko.me/pin-tags/performance/"}]},{"title":"Rendezvous hashing","url":"https://en.wikipedia.org/wiki/Rendezvous_hashing","date":"2026-08-22","permalink":"https://polovko.me/pins/rendezvous-hashing/","summary":"\u003cp>An overview of rendezvous hashing, a simple way to assign objects to servers\nwithout a central coordinator. Each server gets a score from the object\nand server names, and the highest score wins. Every client reaches the same\nresult, and adding or removing a server moves only the objects affected by that\nchange. The article also compares the method with consistent hashing and covers\nreplication, weights, and faster variants.\u003c/p>\n","tags":[{"name":"algorithms","url":"https://polovko.me/pin-tags/algorithms/"},{"name":"hashing","url":"https://polovko.me/pin-tags/hashing/"},{"name":"distributed-systems","url":"https://polovko.me/pin-tags/distributed-systems/"}]},{"title":"The when, why and how of waiting and backoff in multi-threaded applications on Arm","url":"https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/multi-threaded-applications-arm","date":"2026-08-08","permalink":"https://polovko.me/pins/the-when-why-and-how-of-waiting-and-backoff-in-multi-threaded-applications-on-arm/","summary":"\u003cp>An Arm post on what a thread should do while it waits, whether on a lock or\nafter a failed atomic. Spinning in a tight loop is the obvious move, but it\nfloods memory with traffic and slows every other core touching the same\nlocation, so backing off helps both throughput and fairness. The post covers\nbackoff strategies that space out the checks, and the Arm specific tools for\nthem: the counter timer for timed waits, the WFET instruction on Armv8.7 and\nlater that lets a core sleep for a set duration instead of burning power, and\nbarriers like ISB and SB that control how far ahead the processor looks. It also\nlists patterns that look correct but are not, such as empty loops and simple\nLDXR plus WFE combinations, and explains why they fall apart as thread counts\ngrow.\u003c/p>\n","tags":[{"name":"arm","url":"https://polovko.me/pin-tags/arm/"},{"name":"performance","url":"https://polovko.me/pin-tags/performance/"},{"name":"concurrency","url":"https://polovko.me/pin-tags/concurrency/"}]},{"title":"uringscope: Portable, Low-Overhead Observability for io_uring","url":"https://arxiv.org/pdf/2606.15137","date":"2026-08-08","permalink":"https://polovko.me/pins/uringscope-portable-low-overhead-observability-for-io-uring/","summary":"\u003cp>A paper on why io_uring workloads are so hard to see into. Submission and\ncompletion happen in rings shared with the kernel, so strace catches only the\nsetup call and you are left guessing when something goes wrong. uringscope is a\nsingle binary eBPF tool that watches those rings and rebuilds the life of each\nrequest from raw kernel events, using CO-RE, BTF probes, and flexible field\nlookups so one build survives the tracepoint churn across kernel versions. On\nreal NVMe workloads it costs about 0.7 to 9.9 percent of throughput, cheaper\nthan the other tools measured at the same level of detail. The same data feeds a\ndoctor mode that turns raw measurements into named problems with the evidence\nbehind them, aimed at someone chasing a tail latency bug rather than browsing\nhistograms.\u003c/p>\n","tags":[{"name":"io_uring","url":"https://polovko.me/pin-tags/io-uring/"},{"name":"ebpf","url":"https://polovko.me/pin-tags/ebpf/"},{"name":"papers","url":"https://polovko.me/pin-tags/papers/"}]},{"title":"DuckDB Internals: Why is DuckDB Fast?","url":"https://www.greybeam.ai/blog/duckdb-internals-part-1","date":"2026-07-26","permalink":"https://polovko.me/pins/duckdb-internals-why-is-duckdb-fast-part-1/","summary":"\u003cp>A walk through why DuckDB, an in process analytical database, runs SQL so fast.\nIt follows a query from parsing to execution and shows how each step avoids\nextra work: running as a library instead of a server cuts out network and\nserialization overhead, the optimizer pushes filters down and picks join order\nwith dynamic programming, and columnar storage with zone maps lets whole chunks\nof data be skipped when they cannot match a filter. It also explains how a query\nis split into pipelines so the work can run in parallel across threads, each\nwith its own local state. The result is a full picture of the system rather than\na list of buzzwords.\u003c/p>\n\u003cp>There is also a \u003ca rel=\"external\" href=\"https://www.greybeam.ai/blog/duckdb-internals-part-2\">second part\u003c/a>\nfrom the series which covers how those plans actually run: vectorized execution\nin batches of 2048 rows, selection vectors that filter without copying, and a\npush based model that spreads work across CPU cores.\u003c/p>\n","tags":[{"name":"databases","url":"https://polovko.me/pin-tags/databases/"},{"name":"duckdb","url":"https://polovko.me/pin-tags/duckdb/"},{"name":"performance","url":"https://polovko.me/pin-tags/performance/"}]},{"title":"Offloading I/O to Dedicated Cores: An Asymmetric io_uring Backend for Seastar and ScyllaDB","url":"https://www.scylladb.com/2026/07/22/asymmetric-io_uring-backend-seastar/","date":"2026-07-23","permalink":"https://polovko.me/pins/offloading-i-o-to-dedicated-cores-an-asymmetric-io-uring-backend-for-seastar-and-scylladb/","summary":"\u003cp>A ScyllaDB engineering post about a new io_uring backend for Seastar that breaks\nthe usual shared nothing rule, where every core does its own I/O and compute.\nThe asymmetric backend instead sets aside a few cores as dedicated networking\nworkers while the rest run only application logic, and routes I/O syscalls to\nthose workers through io_uring queues. To make it work the team had to remove a\nspeculative fast path that let a shard skip io_uring and issue a plain syscall\non its own core, since that shortcut defeats the point of offloading. The\nnumbers are honest about the tradeoff: raw I/O throughput trails the older linux\naio backend, but compute shards get back the CPU time they used to spend on\nsockets and disk calls.\u003c/p>\n","tags":[{"name":"networking","url":"https://polovko.me/pin-tags/networking/"},{"name":"io_uring","url":"https://polovko.me/pin-tags/io-uring/"},{"name":"databases","url":"https://polovko.me/pin-tags/databases/"}]},{"title":"Aurora DSQL: Scalable, Multi-Region OLTP","url":"https://arxiv.org/pdf/2607.13276","date":"2026-07-18","permalink":"https://polovko.me/pins/aurora-dsql-scalable-multi-region-oltp-2/","summary":"\u003cp>A paper from Amazon engineers on how Aurora DSQL works inside. DSQL is a\nserverless SQL database that runs active active across regions, so any region\ncan take reads and writes at once. The design splits the two apart: reads use\nmultiversion concurrency control with precise timestamps and never coordinate\nwith other nodes, while writes use optimistic concurrency control and coordinate\nonly at commit time, through components called adjudicators and a replication\nlayer called the Journal. Query processors run in small Firecracker microVMs and\nkeep no local state, which lets compute, storage, and coordination scale on\ntheir own, from idle up to millions of transactions per second. The paper shows\nhow all of this keeps full ACID transactions even when an availability zone or a\nwhole region fails.\u003c/p>\n","tags":[{"name":"databases","url":"https://polovko.me/pin-tags/databases/"},{"name":"distributed-systems","url":"https://polovko.me/pin-tags/distributed-systems/"},{"name":"papers","url":"https://polovko.me/pin-tags/papers/"}]},{"title":"Introducing Meerkat: an experiment in global consensus","url":"https://blog.cloudflare.com/meerkat-introduction/","date":"2026-07-11","permalink":"https://polovko.me/pins/introducing-meerkat-an-experiment-in-global-consensus/","summary":"\u003cp>A Cloudflare post about Meerkat, a consensus system they built to keep control\nplane state consistent across their 330 plus data centers. It runs on QuePaxa,\nan algorithm that needs no leader. In Raft a dead leader or a slow network\nstalls writes until a new one is elected, and the timeouts are hard to tune\nacross the wide area internet. QuePaxa instead lets any replica propose a write\nat any time, and concurrent proposals help each other reach agreement rather\nthan block each other. The post is honest about the cost, since each write still\ntakes one to three round trips, so Meerkat suits data that changes rarely and\nmust stay correct rather than a busy database. It is also the first time QuePaxa\nhas run at production scale.\u003c/p>\n","tags":[{"name":"distributed-systems","url":"https://polovko.me/pin-tags/distributed-systems/"},{"name":"consensus","url":"https://polovko.me/pin-tags/consensus/"},{"name":"databases","url":"https://polovko.me/pin-tags/databases/"}]},{"title":"Memory Barriers: a Hardware View for Software Hackers","url":"http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.14a.pdf","date":"2025-03-21","permalink":"https://polovko.me/pins/memory-barriers-a-hardware-view-for-software-hackers/","summary":"\u003cp>Paul McKenney's paper on why memory barriers exist at all, built from the\nhardware up. It starts with how a CPU cache is laid out, then how the MESI\nprotocol keeps caches agreeing on the value of each location, then how store\nbuffers and invalidate queues quietly break that agreement in exchange for\nspeed. Once you see those two queues, read and write barriers stop looking\narbitrary and start looking like the obvious fix.\u003c/p>\n","tags":[{"name":"memory","url":"https://polovko.me/pin-tags/memory/"},{"name":"concurrency","url":"https://polovko.me/pin-tags/concurrency/"},{"name":"hardware","url":"https://polovko.me/pin-tags/hardware/"},{"name":"papers","url":"https://polovko.me/pin-tags/papers/"}]},{"title":"What Every Programmer Should Know About Memory","url":"https://people.freebsd.org/~lstewart/articles/cpumemory.pdf","date":"2025-03-20","permalink":"https://polovko.me/pins/what-every-programmer-should-know-about-memory/","summary":"\u003cp>Ulrich Drepper's long guide from 2007 on how memory hardware really works and\nwhy memory, not the CPU, is often what makes a program slow. It covers how RAM\nchips work, how CPU caches are built and why they exist, and how virtual memory\nand NUMA change the picture, then spends a large middle section on concrete\nadvice for writing code that uses caches well. There are plenty of diagrams and\nreal numbers measured on real hardware, along with practical topics like data\nlayout, cache line size, and tools that help you find memory related slowdowns.\nSome of the hardware details have aged, but the core ideas still hold up.\u003c/p>\n","tags":[{"name":"memory","url":"https://polovko.me/pin-tags/memory/"},{"name":"performance","url":"https://polovko.me/pin-tags/performance/"},{"name":"hardware","url":"https://polovko.me/pin-tags/hardware/"}]},{"title":"A Decade of Dynamo: Powering the next wave of high-performance apps","url":"https://www.amazon.science/publications/amazon-dynamodb-a-scalable-predictably-performant-and-fully-managed-nosql-database-service","date":"2025-01-15","permalink":"https://polovko.me/pins/a-decade-of-dynamo/","summary":"\u003cp>A USENIX ATC paper that looks back at how DynamoDB grew from the original Dynamo\ndesign into a managed service. It shares what the team learned from running the\nsystem at a very large scale and shows how distributed storage works in\nproduction, not just in theory.\u003c/p>\n","tags":[{"name":"distributed-systems","url":"https://polovko.me/pin-tags/distributed-systems/"},{"name":"databases","url":"https://polovko.me/pin-tags/databases/"},{"name":"papers","url":"https://polovko.me/pin-tags/papers/"}]},{"title":"GCRA: a simple and elegant rate-limiting algorithm","url":"https://dotat.at/@/2024-08-30-gcra.html","date":"2024-09-01","permalink":"https://polovko.me/pins/gcra/","summary":"\u003cp>A clear guide to the Generic Cell Rate Algorithm (GCRA), which is used for leaky\nbucket rate limiting. Instead of tracking a counter and refilling it on a timer,\nGCRA stores one timestamp and uses a simple calculation to decide whether to\nallow a request. The post explains the idea step by step and shows why it needs\nlittle memory and is easy to build.\u003c/p>\n","tags":[{"name":"rate-limiting","url":"https://polovko.me/pin-tags/rate-limiting/"},{"name":"algorithms","url":"https://polovko.me/pin-tags/algorithms/"},{"name":"networking","url":"https://polovko.me/pin-tags/networking/"}]}]