Posts

On December 28, 2011, at the 28th Chaos Communication Congress in Berlin, Alexander Klink and Julian Wälde demonstrated something that sent shockwaves through the software industry. With just 2 megabytes of carefully crafted POST data, they kept a single CPU core busy for over 40 minutes. The attack didn’t exploit buffer overflows or SQL injection—it exploited the fundamental mathematics of hash tables. The technique, dubbed HashDoS, works because hash tables have a worst-case performance that’s dramatically different from their average case. When you understand the mathematics behind this vulnerability, you’ll see why it affected virtually every major programming language and why modern hash table implementations look very different from their predecessors. ...

In the late 1970s, Jim Gray and his colleagues at IBM Research were working on transaction processing systems that needed to guarantee data integrity even when power failed mid-operation. His solution was elegant in its simplicity: never write data to the main store until you’ve first written it to a log. This principle, formalized in his 1981 paper “The Transaction Concept: Virtues and Limitations,” became known as Write-Ahead Logging, and decades later, it remains the foundation of every major database system. ...

In October 1986, something alarming happened on the Internet. Data throughput between Lawrence Berkeley Laboratory and UC Berkeley—sites separated by just 400 yards and two network hops—dropped from 32 Kbps to 40 bps. That is not a typo. The throughput collapsed by a factor of 1000. The Internet was experiencing its first “congestion collapse,” and nobody knew how to fix it. Van Jacobson, then at Lawrence Berkeley Laboratory, became fascinated by this catastrophic failure. His investigation led to a landmark 1988 paper titled “Congestion Avoidance and Control,” which introduced the fundamental algorithms that still govern how data flows through the Internet today. The story of TCP congestion control—from those desperate early fixes to modern algorithms like CUBIC and BBR—is really a story about how we learned to share a finite resource without a central coordinator. ...

In 1996, Patrick O’Neil and his colleagues at the University of Massachusetts Boston published a paper describing a data structure that would take nearly a decade to find widespread adoption. The Log-Structured Merge-Tree (LSM-Tree) was designed to solve a problem that barely existed at the time: how to efficiently index data when writes vastly outnumber reads. Today, LSM-Trees power the storage engines of Cassandra, RocksDB, LevelDB, HBase, InfluxDB, and countless other systems that handle massive write throughput. Yet the fundamental insight remains surprisingly misunderstood: LSM-Trees don’t just “write faster”—they fundamentally restructure how data moves from memory to disk. ...

In 1985, three researchers—Michael Fischer, Nancy Lynch, and Michael Paterson—published a result that would fundamentally reshape how we think about distributed systems. Their theorem, now known simply as FLP, demonstrated something unsettling: in an asynchronous distributed system where even a single process can fail, there exists no deterministic algorithm that is guaranteed to solve consensus. This wasn’t a limitation of current technology or a gap in our knowledge. It was a mathematical impossibility—a fundamental boundary that no amount of engineering cleverness can overcome. Yet today, distributed databases coordinate across continents, consensus algorithms power everything from cloud infrastructure to blockchain networks, and systems achieve agreement millions of times per second. How do we reconcile this apparent contradiction? ...

On June 30, 2012, at 23:59:60 UTC, something unusual happened. A single extra second was added to the world’s clocks to account for the Earth’s gradually slowing rotation. Within minutes, Reddit went offline. LinkedIn stopped responding. Mozilla’s servers ground to a halt. Qantas Airways reported that their check-in systems had failed, stranding passengers across Australia. The culprit wasn’t a cyberattack or a hardware failure. It was a bug in how Linux handled leap seconds—a feature that had been tested only a handful of times in the previous decade. The Network Time Protocol (NTP) had warned servers about the incoming leap second, but the kernel’s high-resolution timer subsystem got confused. Applications that were “sleeping” suddenly woke up all at once, overwhelming CPUs. ...

When Google released Chrome in 2008, its JavaScript performance was revolutionary. The secret was V8, an engine that compiled JavaScript directly to machine code rather than interpreting it. But the V8 of 2026 bears almost no resemblance to that original design. Four compilation tiers, speculative optimization based on runtime feedback, and a constant battle between compilation speed and execution speed have transformed JavaScript from a “slow scripting language” into something that routinely outperforms carefully optimized C++ for many workloads. ...

In 1986, David Rumelhart, Geoffrey Hinton, and Ronald Williams published a paper in Nature that would transform artificial intelligence. The paper, “Learning representations by back-propagating errors,” demonstrated that a mathematical technique from the 1970s could train neural networks orders of magnitude faster than existing methods. The speedup wasn’t incremental—it was the difference between a model taking a week to train and taking 200,000 years. But backpropagation wasn’t invented in 1986. Its modern form was first published in 1970 by Finnish master’s student Seppo Linnainmaa, who described it as “reverse mode automatic differentiation.” Even earlier, Henry J. Kelley derived the foundational concepts in 1960 for optimal flight path calculations. What the 1986 paper achieved wasn’t invention—it was recognition. The authors demonstrated that this obscure numerical technique was exactly what neural networks needed. ...

On May 3, 1978, a Digital Equipment Corporation marketer named Gary Thuerk sent a message to 393 ARPANET users advertising a new computer system. The message generated $13 million in sales. It also created a permanent problem that would plague the internet for the next four decades: Thuerk had sent the first spam email. What made this possible wasn’t clever hacking or sophisticated exploitation. It was a fundamental design decision built into email itself—a protocol that assumed everyone on the network could be trusted. When Jonathan Postel published RFC 821 in August 1982, defining the Simple Mail Transfer Protocol (SMTP), he created a system where the sender’s identity was entirely self-declared. Any mail server could claim to be sending from any address, and receiving servers had no way to verify it. ...

A poker site once lost millions because its shuffling algorithm could be predicted. The root cause? A random number generator that wasn’t random at all. The engineers had used a predictable seed, and attackers reverse-engineered the entire deck sequence from just a few observed hands. This wasn’t an isolated incident. From lottery rigging scandals to cryptocurrency wallet thefts, the history of computing is littered with disasters caused by insufficient randomness. Yet here’s the paradox: computers are deterministic machines. They execute the same instruction, they get the same result. So where does randomness actually come from? ...

On September 20, 2015, Amazon DynamoDB in US-East-1 went dark for over four hours. The root cause wasn’t a hardware failure or a cyberattack—it was a feedback loop. Storage servers couldn’t retrieve their partition assignments from a metadata service, so they retried. The metadata service became overwhelmed. More timeouts. More retries. More overload. Engineers eventually had to firewall the metadata service from storage servers entirely, effectively taking DynamoDB offline to break the cycle. ...

At midnight UTC on January 1, 2017, deep inside Cloudflare’s custom RRDNS software, a number went negative when it should have always been at least zero. This single value caused DNS resolutions to fail across Cloudflare’s global network. The culprit? A leap second—one extra tick of the clock that most people never noticed. The bug revealed a fundamental truth that every programmer eventually learns the hard way: time is not what you think it is. It doesn’t flow uniformly forward. It jumps, skips, and occasionally rewinds. And if your code assumes otherwise, it will break in ways that are nearly impossible to predict. ...