DEV Community: Drishti Tripathi

What I Learned Building a Redis Clone in C++

Drishti Tripathi — Sun, 31 May 2026 11:05:41 +0000

What I Learned Building a Redis Clone in C++

A few weeks ago I was studying backend development from first principles. Not frameworks, not tutorials that skip the hard parts — actual fundamentals. How does data get stored? How does a server talk to a client? What even is a database at its core?

That's when I came across Redis for the first time.

I was reading about caching and kept seeing Redis mentioned everywhere. I looked it up and found out it's just a key-value store — you give it a key, it gives you back a value. Fast. Simple. Used by Twitter, GitHub, Snapchat.

And I thought: how hard can it be to build something like that?

Spoiler: harder than I expected. But I learned more from this one project than from weeks of reading.

Here's everything I built, everything I got wrong, and everything I learned.

What Is a Key-Value Store?

Before I get into the code, let me explain what I was even building.

A key-value store is the simplest possible database. Instead of tables and rows like SQL, it just stores pairs:

"name"  →  "Drishti"
"age"   →  "20"
"city"  →  "Delhi"

You store something with a key. You retrieve it with the same key. That's it. Redis is the most popular key-value store in the world and it's used everywhere — caching, session storage, rate limiting, pub/sub messaging.

My goal was to build a simplified version from scratch in C++ and compare it to the real thing.

The Plan

I gave myself a clear roadmap:

TCP server on port 6380
GET / SET / DELETE commands
LRU eviction (automatically remove old keys when store is full)
Disk persistence (data survives server restarts)
Benchmark against real Redis

Let me walk through each one.

Step 1: The TCP Server

The first thing I had to learn was how servers actually work at the socket level. I'd used HTTP APIs before but never thought about what happens underneath.

A socket is just an endpoint for communication. When you connect to a server, both sides get a socket and they use it to send and receive data over TCP.

Here's the core of my server:

SOCKET server_fd = socket(AF_INET, SOCK_STREAM, 0);

sockaddr_in address{};
address.sin_family = AF_INET;
address.sin_addr.s_addr = INADDR_ANY;
address.sin_port = htons(6380);

bind(server_fd, (sockaddr*)&address, sizeof(address));
listen(server_fd, 5);

while (true) {
    SOCKET client_fd = accept(server_fd, nullptr, nullptr);
    // handle client...
    closesocket(client_fd);
}

In plain English:

Create a socket
Bind it to port 6380
Listen for connections
In a loop — accept a client, handle them, close the connection

Why port 6380? Redis uses 6379. I wanted to run both simultaneously for benchmarking, so I picked the next port.

One thing that caught me off guard: on Windows you have to explicitly initialize the socket library with WSAStartup before using any socket functions. On Linux you don't need this. Small difference, but it tripped me up at first.

Step 2: Parsing Commands

Once the server could accept connections, I needed it to actually understand commands.

The client sends a raw string like "set name Drishti". My server receives it as a buffer of bytes. I needed to split it into tokens:

"set name Drishti"  →  ["set", "name", "Drishti"]

I wrote a parser that splits the string by spaces:

std::vector<std::string> Server::parse_command(const std::string& command) {
    std::vector<std::string> tokens;
    size_t start = 0, end = 0;
    while ((end = command.find(' ', start)) != std::string::npos) {
        tokens.push_back(command.substr(start, end - start));
        start = end + 1;
    }
    tokens.push_back(command.substr(start));
    return tokens;
}

Then handle each command based on tokens[0]:

if (cmd == "set")    → store[tokens[1]] = tokens[2]
if (cmd == "get")    → return store[tokens[1]]
if (cmd == "delete") → store.erase(tokens[1])

One bug I hit early: telnet sends \r\n at the end of each command. So tokens[2] would be "Drishti\r\n" instead of "Drishti". The fix was trimming trailing whitespace and newlines before parsing.

Step 3: LRU Eviction

This was the most interesting part to implement.

The problem: memory is finite. If clients keep adding keys forever, the store will eventually run out of memory. I needed a way to automatically remove old keys when the store gets full.

LRU — Least Recently Used — removes the key that hasn't been accessed in the longest time. The logic is simple: if you haven't used something recently, you probably don't need it.

Example with capacity 5:

set a 1   →  [a]
set b 2   →  [a, b]
set c 3   →  [a, b, c]
set d 4   →  [a, b, c, d]
set e 5   →  [a, b, c, d, e]  ← full!
get a     →  [b, c, d, e, a]  ← 'a' just used, moves to front
set f 6   →  evict 'b' (least recently used)
             [c, d, e, a, f]

The implementation uses two data structures together:

A doubly linked list tracks order of use. Most recently used is at the front, least recently used is at the back.

A hash map maps each key directly to its position in the list for O(1) lookup.

List: [f] <-> [a] <-> [e] <-> [d] <-> [c]
Map:  "a" → node, "f" → node, ...

Neither structure alone is enough. The list gives you order but lookup is O(n). The map gives you fast lookup but has no concept of order. Together they give you both in O(1).

Every GET or SET moves that key to the front of the list. When you need to evict, just remove from the back. That's it.

Step 4: Disk Persistence

Without persistence, all data disappears when the server restarts. Not great.

I implemented an Append-Only File (AOF) — the same strategy Redis uses. Every SET and DELETE gets logged to a file:

set a 1
set b 2
set c 3
delete b
set d 4

The file only ever gets appended to — never edited or rewritten. On startup, the server reads the file top to bottom and replays every command:

replay: set a 1    →  {a=1}
replay: set b 2    →  {a=1, b=2}
replay: set c 3    →  {a=1, b=2, c=3}
replay: delete b   →  {a=1, c=3}
replay: set d 4    →  {a=1, c=3, d=4}

Testing this felt satisfying. Set some keys, kill the server, restart it, get the same keys back. It works.

Step 5: Benchmarks vs Redis

The moment of truth. I installed Redis 7.0.15 on WSL and wrote a Python benchmark that sends 1000 SET and 1000 GET commands to both servers:

Operation	My KV Store	Redis 7.0.15
SET 1000 keys	3.55s (281 req/s)	3.19s (313 req/s)
GET 1000 keys	3.55s (281 req/s)	1.12s (892 req/s)

SET is almost equal — only 11% slower. Honestly didn't expect that.

GET has a 3x gap — Redis is significantly faster here.

But here's the thing: this comparison isn't entirely fair. And understanding why it isn't fair taught me more than the numbers themselves.

What the Numbers Don't Tell You

My benchmark script opens a new TCP connection for every single command:

connect → send "set a 1" → receive "OK" → disconnect
connect → send "get a"   → receive "1"  → disconnect

Every TCP connection requires a 3-way handshake (SYN, SYN-ACK, ACK). That's network overhead on every single request. Real Redis clients use persistent connections — one connection stays open and thousands of commands flow through it.

My store isn't slow because C++ is slow. It's slow because of connection overhead that has nothing to do with the actual KV logic.

This was one of the most valuable lessons from the project: benchmarks are only meaningful in context. The numbers matter less than understanding what the numbers are actually measuring.

Other Limitations (Being Honest)

Single-threaded: My server handles one request at a time. Redis uses event-driven I/O (epoll) to handle thousands of concurrent clients on a single thread. Production servers use async I/O or thread pools.

AOF grows forever: My file never gets compacted. Redis periodically rewrites the AOF to remove redundant entries — if a key was set 1000 times, only the last value matters.

No RESP protocol: Real Redis uses RESP (Redis Serialization Protocol), a structured binary format. My store uses plain text, so it's not compatible with redis-cli or any Redis SDK.

LRU capacity is hardcoded to 5: Fine for a demo, not for production.

What I Actually Learned

Going in, I thought this project would teach me about databases. It did — but it taught me much more than that.

TCP sockets from scratch. I now understand what actually happens when two programs communicate over a network. Before this, HTTP was magic to me.

Why data structures matter in practice. LRU eviction is a textbook problem, but implementing it made the O(1) requirement real. You can't just use a list. You can't just use a map. You need both.

The gap between "working" and "production-grade". My store works. Redis works at 1 million req/s under production load. Understanding that gap — connection pooling, async I/O, protocol design, crash recovery — is what separates a learning project from real infrastructure.

Benchmarking is a skill. Writing a benchmark that actually measures what you think it's measuring is harder than it sounds.

First principles learning works. I could have used a Redis client library and moved on. Instead I built the thing. Now when I use Redis in a real project, I'll understand what it's doing.

The Code

Full source code on GitHub: https://github.com/DrishtiTripathi2230/kv-store

The README has a detailed breakdown of every component with diagrams and examples — worth a read if you want to understand any part in more depth.

Tags: #cpp #systems #redis #showdev #beginners

I Built India's Missing Local Transport App — Then Abandoned It for 5 Months

Drishti Tripathi — Fri, 29 May 2026 10:01:38 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

AutoConnect is India's inclusive local transport app — connecting
passengers with auto rickshaws, e-rickshaws, cycle rickshaws, and
single-engine bikes through a single mobile-first platform.

I originally built AutoConnect in December 2025 as a personal project.
I had a clear vision — a transport app built specifically for India's
local vehicles that bigger apps ignore. I designed the full UI, built
every screen, and made it look like a real app. But it was just screens.
Every button was simulated. The README literally said "No backend
integration." I ran out of time, lost momentum, and abandoned it.

5 months later, this challenge made me finally finish what I started.

AutoConnect now has a real Spring Boot backend, a live database, GPS
location detection, real document upload, and a complete ride flow —
passenger requests a ride, driver sees it in real time, accepts it,
and the passenger gets confirmed. All deployed and live.

This project means something to me personally — India's local transport ecosystem is fragmented and most apps ignore auto rickshaws and e-rickshaws completely. AutoConnect is built specifically for that gap, with an accessibility-first UI designed for users with low digital literacy.

AutoConnect is built for drivers that no platform currently serves — cycle rickshaw operators and e-rickshaw drivers in tier 3 and tier 4 towns. These drivers find customers by standing at corners or through WhatsApp contacts. No app exists for them. AutoConnect is built specifically for that gap — simple, accessible, and designed for users with low digital literacy on both sides.

Demo

🔗 Live App: https://auto-connect-mobile-app.vercel.app
🔗 Backend API: https://autoconnect-backend-production.up.railway.app
🔗 Frontend Repo: https://github.com/DrishtiTripathi2230/AutoConnect-Mobile-App
🔗 Backend Repo: https://github.com/DrishtiTripathi2230/AutoConnect-Backend

How to test the full flow:

As a Passenger:

Open the live app → Select "I'm a Passenger"
Sign up with your name and phone number
Enter pickup location (or use GPS) and destination
Click "Find Rides" — this creates a real ride in the database

As a Driver (open in a different browser):

Select "I'm a Driver" → Sign up with vehicle details
Upload documents → Submit
See the passenger's ride request appear on your dashboard
Click Accept — passenger gets confirmed instantly

The Comeback Story

Where it started

In December 2025, I built AutoConnect as a personal project. I had a
clear vision — a transport app built specifically for India's local
vehicles. I spent days designing every screen, every flow, every color.
The UI looked like a real app.

But it was completely hollow.

No backend. No database. No API calls. Every button navigated to a
hardcoded screen. The README admitted it openly:

"Design Focus: UI/UX (No backend integration)"

"This project is a UI/UX prototype intended for design demonstration"

I ran out of momentum and abandoned it for 5 months.

Here's the proof — every commit is from December 23, 2025:

What I changed

When I saw the GitHub Finish-Up-A-Thon challenge, I knew immediately
which project to revive.

Here's everything I built in May 2026:

Backend (built from scratch):

Spring Boot REST API with Driver and Ride endpoints
PostgreSQL database with JPA entities
Driver registration, availability, and ride matching
Ride lifecycle — REQUESTED → ACCEPTED → COMPLETED
Deployed on Railway

Frontend integration:

Connected all UI screens to real backend APIs
Real GPS location detection using browser Geolocation API
Phone number validation (10 digits, numbers only)
Name validation (letters only)
Real file upload for driver documents
Deployed on Vercel

The moment it became real:

When I entered pickup and destination, clicked Find Rides, and saw
"✅ Backend Connected | Ride #3" appear in the corner — that was the
moment 5 months of abandoned work finally felt worth it.

Before vs After

	Before (Dec 2025)	After (May 2026)
Backend	None	Spring Boot + Railway
Database	None	PostgreSQL with real data
Interactions	Simulated	Real API calls
Location	Hardcoded	Real GPS
Validation	None	Phone + name + docs
Deployment	None	Vercel + Railway

My Experience with GitHub Copilot

GitHub Copilot was a genuine partner in finishing this project, not
just autocomplete.

How Copilot helped

The most impressive moment was when I asked Copilot to add fare
calculation for all vehicle types. Instead of just writing a function,
Copilot:

Read my entire codebase automatically — it scanned PassengerHome.tsx and VehicleSelection.tsx before writing a single line
Identified a problem I hadn't noticed — fare rates were duplicated across two components
Created a shared utility file — centralized the fare logic so both screens use the same calculation
Updated 3 files simultaneously — +27 lines, clean and consistent

This wasn't just code generation. Copilot understood the architecture
of my project and made a better decision than I would have made alone.

What I learned

Copilot works best when you give it context. Asking it to "add fare
calculation" while having the relevant files open gave it everything
it needed to make smart decisions about where the code should live.

For a project like AutoConnect — with multiple interconnected components
— that architectural awareness saved me significant debugging time.
— AutoConnect isn't perfect — but it's real now. And that's the whole point of finishing things.