Computer Science

At 23:59:60 UTC on June 30, 2012, a second was added to the world’s clocks. Within minutes, Reddit, LinkedIn, Mozilla, Gawker, and dozens of other major websites had crashed. Their servers were running at 100% CPU, locked in tight loops that made them completely unresponsive. The culprit wasn’t a cyberattack or a hardware failure—it was the handling of a single extra second. The Linux kernel’s high-resolution timer subsystem, called hrtimer, had gotten confused by the leap second. When the system clock stepped backward by one second, sleeping processes were awakened prematurely, flooding the CPU with activity. Java-based applications like Cassandra—the database powering Reddit—were particularly affected. The site was offline for over an hour. ...

On July 20, 2016, Stack Overflow went offline for 34 minutes. The culprit wasn’t a database failure, a network outage, or a cyberattack. It was a regular expression—a tool developers use every day without a second thought. The pattern ^[\s\u200c]+|[\s\u200c]+$ was used to trim whitespace from user-submitted content. When a post containing approximately 20,000 consecutive whitespace characters appeared on the homepage, the regex engine entered a computational spiral that consumed 100% CPU across multiple web servers. ...

In 1959, John McCarthy was building Lisp at MIT when he encountered a problem that would define decades of programming language design. Programs in Lisp created and destroyed linked structures constantly—lists within lists, functions returning functions, recursive structures that no programmer could feasibly track manually. McCarthy’s solution was to make memory management automatic. He called it “garbage collection,” dedicating just over a page in his seminal paper to describe a mark-and-sweep algorithm that would free programmers from the burden of explicit deallocation. ...

Imagine you’re running a service with 10 servers, each capable of handling 1,000 requests per second. You set up a round-robin load balancer—simple, elegant, fair. Every server gets its turn in sequence. Traffic flows smoothly until suddenly, at 2 AM, your monitoring alerts start screaming. Half your servers are overwhelmed, queues are growing, latencies are spiking, and the other half of your servers are nearly idle. What went wrong? The servers weren’t identical. Three of them were newer machines with faster CPUs and more memory. Three were legacy boxes running older hardware. The round-robin algorithm, in its mechanical fairness, sent exactly the same number of requests to a struggling legacy server as it did to a powerful new one. The legacy servers couldn’t keep up, requests piled up in their queues, and eventually they started timing out—cascading into a partial outage that woke up half your engineering team. ...

In 1994, mathematician Peter Shor published an algorithm that would factor large integers exponentially faster than any known classical method. The cryptography community took notice—most of the world’s encrypted communications relied on the assumption that factoring large numbers was computationally intractable. Shor hadn’t built a quantum computer. He had merely proven that if one could be constructed, much of modern security infrastructure would crumble. Three decades later, quantum computers exist. They factor numbers, simulate molecules, and solve optimization problems. Yet they haven’t broken RSA encryption. The gap between having quantum computers and having useful quantum computers reveals something fundamental about the technology: quantum computing isn’t simply a faster version of classical computing. It’s an entirely different paradigm with its own physics, its own constraints, and its own challenges. ...

In 1994, Masahiro Hara faced a problem at Denso Wave, a Toyota subsidiary. Manufacturing plants were drowning in barcodes—each component required multiple labels, scanned one at a time, with workers manually tracking which code corresponded to which part. The existing barcodes could only store about 20 characters. What they needed was something that could hold thousands of characters and be read from any angle, in under a second. The solution Hara’s team developed became the QR code—a matrix of black and white modules that would eventually spread far beyond automotive manufacturing. By 2022, 89 million Americans were scanning QR codes on their phones. But the technical architecture that makes this possible—the Reed-Solomon error correction, the masking patterns, the carefully structured grid—remains largely invisible to the billions of people who scan them daily. ...

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? ...

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? ...