getbetterat.work
Tech Report

Why Software Systems Must Learn to Say "No"

A simple guide to "backpressure" — the safety switch that stops your software from drowning in its own data.

The Water Pipe Problem

The word "backpressure" comes from plumbing. Imagine water rushing through a pipe. If a valve up ahead is half-closed, but the pump keeps pushing water at full speed, pressure builds up.

Eventually, the pipe bursts.

Software is exactly the same. Data flows like water. If one part of your app is slow, data piles up. Backpressure is the system's way of sending a warning back to the pump: "Slow down, or I will crash!"

FAST PUMP
PRESSURE BUILDS
SLOW
Backpressure Needed!

The Math of Waiting (Little's Law)

We can prove why systems crash using a simple math rule called Little's Law. It explains how waiting lines work, whether at a grocery store or inside a computer.

Items = Speed × Wait Time
The formula for system overload
Items (L)

How many tasks are currently inside the computer's memory. If this gets too high, the memory fills up and the computer dies.

Speed (λ)

How fast new requests are coming in from users.

Wait Time (W)

How long it takes to finish one single task.

The Lesson: If tasks take longer to finish (Wait Time goes up), the number of Items stuck in memory will skyrocket. The only way to save the computer is to force the Speed (new requests) to slow down.

What Happens Without Backpressure?

When a computer cannot say "no" to new tasks, it doesn't just slow down—it destroys itself. Here is the domino effect of a crash.

The Cleanup Trap

The computer's memory gets so full of waiting tasks that it spends 100% of its energy trying to clean up old data. It stops doing real work completely.

The Retry Storm

Because the server is slow, frustrated users keep hitting "refresh". This sends even more requests to a computer that is already dying, speeding up the crash.

The Domino Fall

When one server dies, the traffic controller sends its work to the remaining healthy servers. The extra work kills them too. Soon, everything is offline.

Two Ways to Move Data: Push vs. Pull

Push Systems

RISKY

The sender forces data onto the receiver as fast as possible. The receiver is a victim of the sender's speed.

Sender does not care if receiver is busy.
Receiver can easily crash.
Needs complex safety alarms.

Pull Systems

SAFE

The receiver asks for data only when it is ready. If it is busy, it just stops asking for new tasks.

Receiver works at its own pace.
Sender waits patiently.
Built-in safety (impossible to overwhelm).

4 Ways to Protect Your System

01 Wait Rooms

Small Buffers

Create a waiting room for tasks. But it must have a strict size limit. A giant waiting room just hides the problem and creates massive delays (called "Bufferbloat"). Once the small waiting room is full, stop accepting new people.

02 Saying No

Load Shedding

When the computer is full, it immediately drops new requests and tells the user: "HTTP 429: Too Many Requests." Doing this as early as possible saves the computer's energy.

03 Speed Limits

Rate Limiting

Only allow a certain number of tasks per second. Imagine a bucket filled with tokens. Every task costs one token. If the bucket is empty, the task is denied. This smooths out wild spikes in traffic.

04 Smart Talk

Smart Limits (The Netflix Way)

Instead of guessing a hard speed limit, the system constantly checks how fast the network is right now. If things slow down, it automatically lowers the speed limit on the fly.

The Memory Trap (The Cleanup Spiral)

When a computer gets too busy, it fills up its short-term memory with waiting tasks. To make room, it has to pause and clean out old junk data. But if it's too overwhelmed, things go terribly wrong.

1. Memory Fills Up
2. CPU Stops to Clean
3. New Tasks Pile Up
Result: The computer spends 100% of its time cleaning and 0% doing actual work. It freezes forever.

The Traffic Cop Mistake

Big websites use a "Traffic Cop" (Load Balancer) to send users to healthy servers. But without backpressure, this traffic cop can accidentally destroy the whole company.

1

Server A gets slow

It has no backpressure, so it just struggles quietly. The Traffic Cop thinks it is dead.

2

Traffic Shifts

The Traffic Cop moves all of Server A's users over to Server B and Server C.

3

Total Blackout

Servers B and C are suddenly crushed by double the traffic. They crash too. The whole app goes offline in minutes.

The Giant Waiting Room Trap

You might think making the holding area (buffer) bigger is a good idea. It isn't. It causes a nightmare called Bufferbloat.

GIANT WAITING ROOM
Data waits here for 5 seconds
The network thinks everything is fine because nothing is dropped. But the user experiences terrible, unplayable lag.
TINY ROOM
No Wait
If the room is full, data is rejected instantly. The sender realizes there is a problem and slows down. The lag stays at zero.

Smart Traffic Cops (CoDel)

To fix Bufferbloat, engineers invented smart algorithms like CoDel. Instead of looking at how many items are in line, it looks at how long they have been waiting.

The 5 Millisecond Rule

If a piece of data waits in line for more than 5 milliseconds, the system flags it as a "Bad Line".

It immediately starts dropping new data on purpose. This dropped data acts as a flare gun, warning the sender to drastically reduce its speed.

The Ticket System (Reactive Streams)

A modern way to code software is to use a "Ticket System". The receiver is in total control and tells the sender exactly how many pieces of data to send.

OFFICIAL REQUEST
5
I am ready for exactly 5 items. Send no more until I ask again.

Auto-Adjusting Limits

Hard-coded speed limits (like "only allow 100 users") break when servers get sick. Smart companies use auto-adjusting limits that test the waters constantly.

When Fast...

Speed Up

If tasks finish quickly, the system slowly turns the speed limit up, allowing more traffic in.

When Slow...

Brake!

If tasks start taking too long, the system slams on the brakes and cuts the allowed traffic in half instantly.

The Internet's Secret Weapon (TCP)

The entire internet already uses backpressure at its core. It is built into TCP, the rulebook computers use to talk to each other across the globe.

SENDER: I am sending 1,000 bytes of data.
RECEIVER: Got it. My holding room is getting full. My "Window Size" is now 500.
SENDER: Okay, sending 500 bytes.
RECEIVER: Got it. I am completely full. My "Window Size" is 0.
SENDER: Understood. I will wait until you say you have space.

When Your Screen Freezes

Backpressure isn't just for heavy backend servers. It happens right on your screen. If a website tries to update too much data at once (like a crazy stock market chart), your browser locks up.

The "Main Thread" Jam

Web browsers do almost everything on one single track called the Main Thread. If you push data onto that track faster than the screen can draw it, your mouse stops working, buttons won't click, and the page freezes.

Unfreezing the Browser

Web developers use specific tricks to add backpressure to the screen so it always stays smooth and clickable.

Frames

Instead of updating the screen every time new data arrives, the browser collects it and updates exactly 60 times a second.

Faking Lists

If a list has 10,000 items, the browser only draws the 10 items you can see right now. The rest don't exist until you scroll.

Helpers

Heavy math is kicked off the Main Thread and given to background "Web Workers" so the screen never gets blocked.

The "Fail Fast" Rule

In the 1980s, tech experts realized a critical truth: It is better for a machine to stop completely than to work slowly and incorrectly.

If a system accepts every task, it enters a zombie state. It tries to do everything, but fails slowly at all of it. Backpressure forces the system to fail fast on a few tasks so the rest of the system can stay alive.

By saying "no" to a few tasks, the system says "yes" to its own survival.