Everything is a pipe

Aqueducts, bloodstreams, TCP/IP. Same pattern, same solution.

I had a weird realization the other day. I was reading about how the internet routes packets through TCP, and something in my brain went "wait, this is just plumbing." Not metaphorically. Not in a cute, hand-wavy way. I mean the engineering is structurally identical to plumbing. The solutions are the same. The failure modes are the same. The math is the same.

And then I looked at blood circulation. Also plumbing. And then I looked at Unix pipes. Also plumbing. And then oil pipelines, electrical grids, supply chains — all plumbing. Everything is plumbing.

This should not have been as unsettling as it was.

1. Rome didn't fall, it leaked

The Roman aqueduct system is one of the most impressive engineering achievements in human history, and also basically a gravity-powered municipal water API.

Here's how it worked. You find a source of clean water in the hills — a spring, a lake, whatever — and you build a channel from there to the city. The channel has a very slight downward gradient. We're talking about 1 meter of drop for every 4,800 meters of horizontal distance. That's barely a slope. That's less slope than most people's driveways. And yet water flows through it, reliably, for hundreds of kilometers, powered by nothing but gravity and the quiet confidence of Roman engineering.

But here's where it gets interesting. The water doesn't go straight from the hills into your mouth. It hits a castellum divisorium first — a distribution tank at the city's edge. This tank splits the incoming flow into multiple smaller pipes heading to different neighborhoods.

Sound familiar? It should.

It's a load balancer. Same concept. Same function. Two thousand years earlier.

And when demand in one neighborhood spiked — say, everyone in Trastevere decided to take a bath at the same time because Trastevere apparently had one hobby — the flow to other neighborhoods would drop. So the Romans built reservoirs. Holding tanks that accumulated water during low-demand periods and released it during peaks.

That's a buffer. Literally a buffer. They invented buffering to manage throughput in a distributed delivery system and they did it using rocks.

They also had redundant supply lines. Rome had eleven aqueducts feeding the city. Not because one wasn't enough, but because if the Goths cut your water supply, you want a failover. Redundancy. Fault tolerance. High availability. The Romans built a four-nines uptime water system using concrete, arches, and slave labor, and it ran for five hundred years without a version update.

Anyway.

2. Your blood is enterprise middleware

Let's talk about the circulatory system, which is — and I cannot stress this enough — also a pipe.

Your heart pumps blood. That blood carries oxygen (the payload) inside red blood cells (the packets) through arteries (the trunk lines) down to capillaries (the last-mile delivery network) and back through veins (the return path). This is a packet-switched delivery network. It has routing. It has flow control. It has congestion management. It has better uptime than most things humans have intentionally built.

Key conceptWhen a muscle needs more oxygen — say, you're running from something with teeth — your body dilates the arterioles feeding that muscle, increasing flow. Simultaneously, it constricts arterioles to less critical areas. Your digestive system can wait. You're being chased. This is dynamic bandwidth allocation. Your body is doing QoS routing in real time, prioritizing critical traffic over background processes. It figured this out roughly 400 million years before Cisco did.

And the failure modes? Hilariously familiar.

An aneurysm is a buffer overflow — a section of pipe that expanded beyond spec and burst. A blood clot is a packet that got stuck in the pipe and blocked all downstream traffic — a deadlock with fatal consequences. Atherosclerosis — plaque buildup in arteries — is literally pipe corrosion reducing throughput over time. Your cardiologist is basically a plumber with a medical degree and better handwriting.

Your body even has error detection. If a blood vessel gets damaged, platelets rush to the site and form a clot to seal the leak. That's a self-healing mechanism. Your circulatory system has better incident response than most Series B startups.

Here's the kicker: the total length of blood vessels in a human body is roughly 100,000 kilometers. That's enough to wrap around the earth two and a half times. You are carrying a pipe network longer than most countries' highway systems, and it runs 24/7 without a maintenance window for about 80 years.

Try getting that SLA from AWS.

TCP/IP: the internet is literally plumbing

When Vint Cerf and Bob Kahn designed TCP in the 1970s, they probably weren't thinking about Roman aqueducts or hemoglobin. But they independently arrived at the exact same solutions to the exact same problems. Because the problems are the same. Because everything is a pipe.

TCP breaks your data into packets (chunks of bytes — little buckets of water). It numbers them sequentially so the receiver can reassemble them in order, even if they arrive scrambled. It sends them through a network of routers (junctions in the pipe system). And it implements flow control to avoid overwhelming the receiver.

The Congestion WindowTCP doesn't just blast data at full speed. It starts slow — sends one packet, waits for acknowledgment. Then two. Then four. Doubling each time. This is called slow start, and it's TCP's way of probing the network's capacity without flooding it.

If packets start getting dropped (the pipe is full), TCP halves its sending rate immediately. This is congestion avoidance. It's the exact same principle as Roman reservoirs managing demand spikes — buffer when you can, throttle when you must.

Vint Cerf reinvented the sluice gate. Using math. In the 1970s. Wearing a three-piece suit, presumably.

And just like the Romans built redundant aqueducts, the internet routes around failures. If one path goes down, packets find another way. That's not a feature someone added later — it's the fundamental architecture. The internet was designed so that you could literally nuke a chunk of it and traffic would reroute automatically.

Cold war engineering at its finest.

cat universe | grep pattern

And then there's Unix pipes. Which might be the purest, most distilled expression of this whole concept.

In 1973, Ken Thompson and Dennis Ritchie — while building Unix at Bell Labs in their spare time like it was a weekend project and not the foundation of all modern computing — introduced the pipe operator: |. It takes the output of one program and feeds it directly into the input of another. No intermediate files. No manual copying. Just a stream flowing from one process to the next.

BASH Copy

cat server.log | grep "ERROR" | sort | uniq -c | sort -nr | head -20

That one line reads a log file, filters for errors, sorts them, counts unique occurrences, sorts by frequency, and shows the top 20. Six programs. Zero of them know the others exist. They just read from a pipe and write to a pipe. Beautiful. Elegant. Plumbing.

TipThe Unix philosophy is literally "do one thing well and connect to everything via pipes." Each program is a simple, specialized valve in a pipeline. The power comes from composition, not complexity. This is the same reason Roman aqueducts used standardized pipe diameters — interchangeable components, composable infrastructure. Ken Thompson and a Roman hydraulic engineer would have had a great conversation if you could get past the language barrier and the 2,000-year gap.

And the backpressure mechanism is perfect. If the receiving program can't process data fast enough, the pipe buffer (typically 64KB on Linux) fills up. When it's full, the sending program just... stops. Blocks. Waits. No data loss. No overflow. The slow consumer controls the pace of the fast producer.

Your blood vessels do the same thing. TCP does the same thing. Roman sluice gates did the same thing.

3. The pipe you're training

Every example so far is a pipe that moves something through space — water, blood, packets, text. But there's a pipe that moves something through abstraction, and it follows every rule in the table below.

A machine learning pipeline is a Unix pipe with extra steps and a GPU bill.

Copy

raw text → tokenizer → embeddings → attention layers → output logits → token

Six stages. Each one reads from the previous, transforms, writes to the next. None of them need to know what the others are doing. The tokenizer doesn't care what the attention heads will find interesting. The attention heads don't care how the text was split. They just read from the pipe and write to the pipe. This is cat | grep | sort | uniq wearing a lab coat.

And the flow control is identical.

Batch size is backpressure. A GPU has finite memory — it can only process so many samples at once. Push too many through and you OOM1. So you batch. Send 32 samples, wait for the forward pass to clear, send the next 32. The slow consumer (GPU memory) controls the pace of the fast producer (your dataset). This is Unix pipe backpressure. This is TCP congestion windowing. This is a Roman sluice gate made of silicon.

1Out Of Memory — the GPU equivalent of a burst pipe. The buffer is full, the next write has nowhere to go, and the whole process crashes.

KV cache is buffering. During inference, a transformer doesn't recompute attention over every previous token from scratch. It caches the key-value pairs from previous positions — a reservoir of precomputed work that future tokens draw from without re-deriving it. The KV cache accumulates during the early part of a sequence (when context is short and cheap) and gets drawn down as the sequence grows. When it fills up, you either spill to recomputation or you stop generating. This is a reservoir. It behaves like one. It fails like one.

Gradient accumulation is flow control. When your batch doesn't fit in memory, you don't give up — you accumulate. Process a micro-batch, store the gradients, process another, add them up, repeat. Only update the weights when you've collected enough. This is exactly what TCP does with its congestion window: send a little, confirm receipt, send more, confirm, aggregate into one stream. The optimizer doesn't see micro-batches. It sees one big update. Same way the receiving end of a TCP connection doesn't see individual packets — it sees a continuous flow.

{bkqt/The layer nobody extended} Martin Kleppmann wrote the book on this — literally. Designing Data-Intensive Applications traces the pipe pattern from batch processing through stream processing through Kafka, through exactly the kind of flow-control math that makes distributed systems work. He stopped at the data infrastructure layer. Nobody extended it into the model itself. But the model is the pipe. The transformer architecture is a pipeline of transformations with buffering, flow control, and backpressure, running on the same math that governs TCP windows and Roman water pressure. The book ends one abstraction layer too early. {/bkqt}

4. The table that shouldn't exist

Here's where it gets properly eerie.

concept aqueducts blood TCP unix pipes ML pipeline

payload water oxygen data packets text streams tensors

conduit stone channels arteries / veins cables / fiber file descriptors layers / forward pass

buffer reservoirs spleen socket buffer pipe buffer (64KB) KV cache

flow control sluice gates vasoconstriction congestion window backpressure gradient accumulation

load balancing castellum heart chambers routers / BGP tee / split batch distribution

error detection human inspection platelets checksums exit codes loss function

redundancy 11 aqueducts collateral circulation multi-path routing fallback pipes multi-head attention

Seven solutions. Six domains. Every column fills every row. Independently discovered across two thousand years and five completely different substrates by people who had absolutely no idea the others existed.

That table should be illegal.

Why this keeps happening

Okay so hydraulic engineering, evolutionary biology, packet networking, and operating system design all converge on identical solutions. That's not a coincidence. That's not even a pattern. That's a structural inevitability.

Here's why. Every pipe system shares the same fundamental constraint: you have a producer, a consumer, and a channel with finite capacity between them. That's it. That's the whole problem. And there are only so many mathematically valid solutions to that problem.

Key conceptThis is what queuing theory formalizes. Little's Law — published in 1961 but applicable to Roman water systems and human arteries alike — states:

L = λW

The average number of items in a system (L) equals the average arrival rate (λ) multiplied by the average time each item spends in the system (W). It doesn't care if L is packets, water molecules, or red blood cells. The math is identical. The math was always identical. Little's Law doesn't know what domain it's solving for, and that's the point.

The reason every pipe system discovers buffering is that variable demand plus fixed capacity equals overflow without a buffer. The reason every pipe system discovers flow control is that unregulated producers will always overwhelm finite channels. The reason every pipe system discovers redundancy is that single points of failure will, given enough time, fail.

These aren't design choices. They're theorems. Any engineer building any pipe system will rediscover them, because they are properties of the problem space, not the solution space. The Romans didn't choose to invent buffering. Buffering chose to be necessary. Evolution didn't design vasoconstriction. Physics demanded it.

· · ·

I keep coming back to a line that sits on the front page of this site: engineering is engineering — the substrate doesn't matter.

I used to think that was a nice sentiment. A philosophical position. A way of saying "I work across domains and that's cool."

Now I think it's a mathematical statement. And the proof is sitting in a table comparing Roman concrete to red blood cells to TCP congestion windows, and all three columns say the same thing.

The patterns that work in pipe engineering are the patterns that work. Period. Doesn't matter if the pipe carries water, blood, photons, or bytes. The physics of flow through a bounded channel produces the same constraints, and the same constraints produce the same solutions. Every time. Everywhere. For two thousand years and counting.

Which means if you deeply understand one pipe system — I mean really understand it, down to the failure modes and the math — you already understand all of them. The transfer is free. The knowledge is portable. The only thing that changes is what's flowing through the tube. Water, blood, photons, bytes, tensors — doesn't matter.

And the tube, as it turns out, doesn't care.