Why we kept the Redis protocol instead of inventing an API
Every new API is a tax on adoption: clients, docs, muscle memory, tooling. RESP3 meant inheriting twenty years of all four on day one.
The tempting move for any new infrastructure product is a bespoke API — clean, modern, yours. The cost hides in the ecosystem: every language needs a client, every client needs maintenance, every team needs to learn error semantics, and every debugging session starts from zero tooling. Protocol invention is a decade of work cosplaying as a design choice.
Speaking RESP3 bought all of it back: redis-py, ioredis, Lettuce, and dozens of mature clients connect to Crowkis unmodified; existing health checks, dashboards, and operational reflexes mostly just work; and the crowkis cli feels familiar to anyone who's typed redis-cli. Adoption friction drops to 'change the port.'
Four doors in, one cache, and the model only sees genuinely new questions.
The protocol carries the semantic extensions gracefully — CSET, CGET, CSIM and family are ordinary commands with ordinary arguments, negotiated over the same HELLO handshake, with hard frame caps and constant-time auth at the door. Redis-compatibility never meant inheriting Redis's matching; the brain behind the protocol is entirely ours.
The bottom line
For shops with different tastes, gRPC, REST, and MCP front the same engine. But RESP is the people-mover: the fastest path from 'heard of it' to 'first hit in the dashboard' is a protocol your stack already speaks.