Redis

A key-value store sounds simple: accept a command, look up a key, return a value. The interesting work starts when those commands have to cross a socket. A server needs a wire format, a parser that can handle input arriving in pieces, and a clear answer to the question of who owns the data after a command has been processed. I implemented a tiny version of Redis to make those pieces small enough to see at once. It is a single-threaded C server that speaks a useful subset of Redis’s RESP protocol and supports PING, ECHO, SET, and GET. The implementation is deliberately limited, but it has the same basic shape as a real network service: create a listening socket, accept a connection, parse requests, execute commands, serialize replies, and manage memory that outlives an individual request. ...

Most RAG demos stop at the happy path: split a PDF, embed the chunks, retrieve the nearest neighbors, put them in a prompt, call a model. That is the right starting point, but it leaves out the parts that make the system feel like an actual assistant instead of a stateless search box. I built a small agent in Python to explore those missing pieces. It is a FastAPI service with two main endpoints: /ingest for uploading documentation and /ask for asking questions against it. Under the hood it uses Redis Stack via redisvl for vector and full-text search, OpenAI for embeddings and answer generation, and Redis again for sessions, semantic cache entries, long-term memory, and metrics. ...