Velocity · in-memory data store · Rust · in progress
Still building this one
Velocity is an in-memory data store written from scratch in Rust, speaking the Redis protocol. It is early: there is a server that accepts a connection and the beginnings of the wire format, and not much else yet.
Still open
This page is here because the project is, not because it is finished. There are no benchmarks to quote and nothing has been run in anger. Everything below is either what exists today or what it is being built towards, and which is which is marked.
What runs today
A TCP listener on the Redis port that accepts one connection at a time, reads what arrives into a buffer and writes it straight back. Alongside it, the start of the wire format: a value type for the two shapes that matter, and encoders that turn them into bytes.
So: it can hold a socket open and it can produce a well-formed reply. It cannot yet read one, and there is nothing behind it to store anything in.
Written and not written
Piece
State
TCP accept loop
Written. One connection at a time, echoing what it receives. Enough to prove the socket works and no more than that.
Protocol encoding
Written. Bulk strings and arrays go out in the right shape, length prefixes and line endings included.
Protocol decoding
Not written. Until this exists the server cannot tell one command from another, which is the next thing to do.
The store itself
Not written. This is the actual subject of the project and none of it exists yet.
Concurrency
Not written. One connection at a time today. How many readers can share a keyspace at once is the interesting question and it has not been asked yet.
The point is the part underneath
There is no shortage of in-memory data stores, and this is not an attempt to compete with one. The reason to write it is that the interesting engineering is all in the layer you normally never touch: how memory is laid out, what a value costs to store, and how many readers can share a keyspace at once without stepping on each other.
Rust is the right language for that specifically because it will not let those questions be avoided. Ownership makes the concurrency model something you have to state rather than something you hope about.
No crates, deliberately. The dependency list is empty and staying that way for as long as it can, because pulling in a runtime or a parser would hand over exactly the parts worth writing.
In this order
Decode the protocol, so a command can be told apart from its arguments. Then the smallest possible store behind it, get and set over a map, single threaded and slow. Only then the part this is really for: making it safe for many connections at once, and finding out what that costs.
The diagram on the card is that shape, not this one. It is drawn from where this is going rather than from what is here, and it will get redrawn from the code once there is code to draw it from.