Netflix 面臨的真實問題

One Slow Service, Whole Site Down

Netflix serves a huge number of requests every second. Each page a user opens triggers calls to many backend services behind the scenes.

Most of the time, those services answer quickly.

But when just one dependency becomes slow, something surprising happens. Within seconds, the entire application can stop responding, even for features that never touch the slow service.

This lesson explains why.

Every Request Holds a Thread

A web application has a limited pool of resources: threads, connections, and memory.

When a request arrives, the app gives it a thread. That thread stays busy until the backend answers.

While the thread waits, it does no useful work. It also cannot be used by anyone else.

Notice that every thread linked to the slow dependency sits idle, so fewer threads remain for the requests lining up.

Fast answers mean threads return to the pool quickly and serve the next request.

Slow Is Worse Than Down

It sounds backwards, but a slow dependency is often more dangerous than a dead one.

If a service is down, calls fail fast. The thread gets an error, returns to the pool, and moves on.

If a service is slow, every call hangs. Threads stay stuck waiting, sometimes for many seconds.

A fast failure frees resources. A slow answer holds them hostage.

How Seconds Become Collapse

High traffic is what turns a slow call into an outage.

New requests keep arriving at the same rate. Each one grabs a thread and joins the wait.

If each call takes ten times longer, each thread stays busy ten times longer. The app suddenly needs far more threads than it has.

At high traffic, the pool empties in seconds. New requests then queue up or get rejected.

The Failure Spreads

Once the pool is empty, the damage is no longer limited to the slow feature.

Healthy features need threads too. With none left, they fail even though their own backends are fine.

Any service calling this app now waits as well. Its threads get stuck, and the slowdown travels upward.

This chain reaction is called a cascading failure.

Spotting It in Your Systems

This problem is not unique to Netflix. Any busy app that calls other services can face it.

Watch for these signs: threads stuck waiting, response times climbing everywhere, and unrelated features failing together.

The core lesson is simple. Shared resources plus slow calls plus high traffic can take down everything.

Protecting the app starts with stopping one dependency from holding all the threads.

For a busy web app, a backend dependency that becomes _____ is usually the more dangerous situation for the app's thread pool.

• very slow
• completely down

Answer: very slow

When a service is down, calls fail fast and threads return to the pool. When it is slow, every call hangs and threads stay stuck waiting, holding resources hostage.

When a request arrives, the app assigns it a _____. If a dependency is slow, that thread keeps _____ and cannot serve others. Once the _____ is empty, new requests queue up or get rejected.

Answer: When a request arrives, the app assigns it a thread. If a dependency is slow, that thread keeps waiting and cannot serve others. Once the pool is empty, new requests queue up or get rejected.

Each request occupies a thread until the backend answers. Waiting threads do no useful work and can't be reused, so slow calls drain the limited pool, after which new requests are queued or rejected.

An app receives requests at a steady, high rate. One backend it calls suddenly takes 10 times longer to respond. What happens to the app's thread usage?

• It needs roughly 10 times more threads at once, so the pool can empty within seconds
• It stays the same, because the number of incoming requests has not changed
• It drops, because threads that wait longer consume less CPU
• It rises slightly, but only requests to the slow backend are affected

Answer: It needs roughly 10 times more threads at once, so the pool can empty within seconds

Arrival rate stays the same, but each thread is busy 10 times longer, so far more threads are needed simultaneously. At high traffic the limited pool empties in seconds.