Full-Stack Developer, Application Architect, Quality Assurance, Performance Optimiser, Code Sleuth, Project Manager, always learning.

This is the second post in a series of posts about building a Redis client from scratch. In the first post, we explored the Redis protocol and the basic commands that a Redis client needs to support.

Having collected most of the clues we need to solve the mystery of the Redis client, we can now start putting the pieces together and see how they fit. Once we have identified the key components of the Redis client, we can start to understand how they interact with each other and how they can be used to build a working client.

I will use TDD to both articulate our understanding of the Redis client and to validate our assumptions. We will start by writing a test that will fail because the Redis client does not exist yet. We will then create the Redis client and implement the minimum functionality required to make the test pass. We will continue to write tests and implement the necessary functionality until we have a working Redis client.

Using TDD allows me to focus on the immediately relevant parts of the Redis client without getting distracted by gold-plating, nice-to-have features, and premature optimization. This also means we can safely build the RedisClient incrementally and safely revise our design as new facts become apparent. This approach will help us to understand the Redis client better and to identify any gaps in our knowledge. It will also help us to identify any missing pieces of the puzzle that we need to find.

While planning out the next installment of the “Case of the Redis Client”, I remembered a case from a few years ago that was causing us serious problems at CodeProject. We were using Redis to cache a lot of data and UI, which drastically improved the User Experience and resource usage. However, occasionally the Redis Client, StackExchange.Redis, would lock up and timeout on all requests. We have 4 front-end webservers, and when the issue occurred, most, if not all, of the webservers would start reporting Redis errors.

Needless to say, the site would slow down to a crawl and become unusuable. This is the story of how I uncovered the unlikely culprit.

The Case of the Redis Client is a series of posts that will explore the design and implementation of a Redis client from scratch. In this first post, we will collect the clues and information needed to solve the case, and set the stage for the investigation. This is one of my oldest ‘Cold Cases’.

Over the years, when trying to learn or understand a new technology, I have found that the best way to do so is to build something with it. This hands-on approach allows me to explore the technology in depth, understand how it works, and identify any issues or limitations. It also gives me the opportunity to experiment with different features and configurations, and to see how they affect the performance and behavior of the system.

One technology that I have been interested in for a while is Redis, an open-source, in-memory data structure store that can be used as a database, cache, and message broker. Redis is known for its speed, simplicity, and flexibility, and is widely used in web applications, real-time analytics, and other use cases where high performance and scalability are required.

Writing a Redis client seemed like a good way to learn more about Redis and its features, as well as to explore the design and implementation of a networked client-server application. In this series of posts, I will share my experiences in building a Redis client from scratch, and the challenges and insights that I encountered along the way.

Welcome to the Code Sleuth blog! I am a software developer and detective, and I will be sharing my adventures in solving mysteries and puzzles in the world of software development. Each post will focus on a different case, and we will collect the clues and information needed to solve it. I will also provide the solutions to the cases, so you can see how I solved them. I hope you enjoy reading about my adventures as much as I enjoy solving them!