Introduction

The years spanning from 1993 to 2015 were extraordinary. Linux and FreeBSD became mainstream server operating systems. The web evolved from serving static files to deploying containerized applications through complex pipelines. Most of this innovation was done in the open, often by people collaborating across organizational and geographic boundaries.

Building the Web is a book about how these contributions were made by practitioners working in specific contexts under specific constraints, and how their innovations compounded — sometimes unexpectedly. Rather than treating each innovation in isolation, this series aims to illuminate the connections between developments that were often happening in parallel.

Why These Stories Matter

As practicing engineers, reading the history of major innovations and paradigm shifts will help us appreciate the system design principles that lasted. It’s often the case that major innovative ideas can also be retooled towards new classes of problems. Learning about the constraints faced and approaches taken by inventors of some of the modern web’s most foundational ideas can help us make more informed decisions when designing systems. Security is a common thread that runs through each chapter — every innovation both solved problems and introduced new vulnerabilities.

The Pattern

Each chapter of Building the Web will follow a similar pattern:

  1. The constraint. Something broke, or was about to. Traffic was growing, hardware was failing, users were waiting too long.
  2. The solution. Someone had an idea - sometimes elegant, sometimes a hack held together with duct tape. But it worked.
  3. The evolution. Other people faced similar problems and adapted the solution. It got formalized, standardized, commercialized.
  4. The modern form. Today’s version of the idea, shaped by decades of iteration. Often unrecognizable from the original, but built on the same foundation.

Who This Is For

This series is for engineers and anyone who wants to deep dive on how web architectures have evolved over time. If you’re senior enough to have opinions about system design, you’ll find the historical context illuminating. If you’re earlier in your career, you’ll get a foundation that most people only acquire through years of accumulated folklore.

You don’t need to know the history to use a CDN. But knowing it makes you better at deciding when you need one - and what to do when it’s not enough. Understanding the process of innovation also helps you understand when you can repurpose fundamental ideas to solve entirely new problems.