Posts

This article is about building a distributed cache like Redis and learning the concepts around it. Things we will cover RESP protocol communication Client interface to interact with Redis Handling load Persistence in both modes, just like Redis: append-only file and RDB file Crash recovery Replication (in next part) Master / Replica architecture (in next part) Lets dive in. First and foremost, the most essential part is communication between the client and server....

Lets just jump right into it. So I created a Database, its just a Wrapper around CSV file writer, a fancy one that does some CRUD and file management, some validations and if input is given in correct format, it preserves it in the file. When I need it, I can request the part(s) so it pulls it out for me, from the specific file. Here’s the structure of my database: an interface for inputting queries (selection, insertion, and other operations), a process layer that parses the query, identifies its type and operation, extracts values, and creates a parsed version for the Executor....

Now that we’ve covered why a B+ Tree is useful, let’s dig a little deeper and see how we can actually implement one. PostgreSQL offers a detailed explanation of how they’ve built their B+ Tree, touching on all the critical aspects needed for a production-ready system. You can check out their implementation here: PostgreSQL B+ Tree Implementation. In this article, we’ll keep things simple and focus on the core functionalities of a B+ Tree....

This discussion is based on learning about sockets from scratch to trying to build an application. Basic Google definition is: A socket is a communication endpoint in a computer network that allows two computers to communicate with each other. So, on a daily basis, for simplicity, we use WebSockets, or more accurately, we use a library for WebSockets. The WebSocket protocol, which is a browser-focused extension of sockets, uses TCP sockets behind the scenes....