The Best Code is the code I did not write

Last weekend, I wrote about my learning journey and how I designed and implemented a high performance worker pool mechanism.

Using just a couple of lines of code, I can spin up a worker pool and handle tasks at lightning speed. While building a Redis caching mechanism, I used the worker pool to handle asynchronous cache population. That means when there is a cache miss, the system fetches data from the data source and saves it into Redis. So next time, there will be no cache miss.

Building a Reusable Worker Pool for Background Work

This design is very important if we want to serve data to the client side at lightning speed.

Throughout this week, I spent time designing worker pools using goroutines, wait groups, channels, sync.Map, mutex, and understanding deadlocks and concurrency concepts deeply.

At some point, I started asking myself: “Why can’t I use a worker pool for everything?”

My mind was telling me to handle everything using threads. If it works, why not use it everywhere? Other developers must have done the same before me, right?

So I started digging deeper. I analyzed multiple use cases and different scenarios.

At the end, I realized something important.

Yes, as a Go backend developer, the real power is that we can use threads almost like writing a simple hello world. We can build powerful concurrent systems very easily. But sometimes, that can become overkill.

We might design and implement worker pools beautifully. But if the traffic is low, or the workload does not require concurrency, then that pooling becomes unnecessary overhead for the server.

The best code I wrote last week was actually the code I decided not to write.

In my initial design, I planned to use a worker pool not only for cache population but also for reading data from Redis using multiple threads. I planned to wait until all threads completed and then hit the internal API.

But then I asked myself: “What is the actual traffic in the existing platform?”

The answer: maximum 6 cache reads per client request.

Handling that with multiple threads would be overkill. It would add complexity without real benefit.

So I decided to use worker pools only for cache population, because the client does not need to wait for that. It runs asynchronously in the background. That makes sense.

And the lesson I learned this week is:

“The best code is the code I did not write.”