Why Creating a Thread for Every Client Is a Bad Idea

Imagine you’re building a web server.

A client connects, sends a request, and waits for a response.

The simplest solution seems obvious:

new Thread(() -> handle(clientSocket)).start();

One client, one thread.

Problem solved.

At least that’s what I thought while building a simple multithreaded web server in Java.

My server accepted connections using ServerSocket, and whenever a client connected, I initially considered creating a new thread to handle the request. It worked perfectly during testing, but it made me wonder:

What happens when hundreds or thousands of clients connect simultaneously?

If 10 clients connect, you create 10 threads.

If 100 clients connect, you create 100 threads.

If 1,000 clients connect, you’re suddenly managing 1,000 threads, each consuming memory and CPU resources. At some point, the server spends more time managing threads than processing requests.

This is exactly the problem thread pools were designed to solve.

Enter Thread Pools

Instead of creating a new thread for every request, a thread pool creates a fixed number of worker threads and reuses them.

ExecutorService pool =
    Executors.newFixedThreadPool(5);

While building my server, I configured a pool of five worker threads and launched twenty clients simultaneously.

The result was surprisingly simple:

• The first five requests were processed immediately.
• The remaining requests waited in a queue.
• As soon as a worker thread finished its task, it picked up the next request.

No new threads needed to be created.

That’s when the main idea clicked for me:

A server doesn’t need unlimited threads. It needs to use threads efficiently.

Then I Discovered the Event Loop

While reading more about concurrency, I came across the Event Loop architecture used by Node.js.

At first, I assumed it was simply another way of implementing multithreading.

It isn’t.

With a thread-pool model, requests are assigned to worker threads.

With an Event Loop, asynchronous operations are delegated and callbacks are executed when the work completes. Instead of dedicating a thread to every request, the system keeps moving and reacts when events are ready.

This makes the Event Loop especially effective for I/O-heavy workloads such as APIs, chat applications, and real-time systems.

Thread Pool vs Event Loop

Both approaches solve the same problem:

How can a server handle many requests without wasting resources?

A Thread Pool does it by reusing a limited number of worker threads.

An Event Loop does it by avoiding dedicated threads for most waiting operations and relying on asynchronous callbacks.

Different approaches.

Same goal.

Final Thoughts

Building a multithreaded web server taught me much more than socket programming.

It helped me understand why thread pools exist, why creating a thread for every client doesn’t scale, and how different platforms approach concurrency.

Most importantly, it showed me that technologies like Tomcat, Spring Boot, and Node.js aren’t magic. They’re all solving the same fundamental problem: handling many requests efficiently.

Sometimes the fastest way to understand a system is to build a smaller version of it yourself.