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.'
- 1your app · redis-py · ioredis · Lettuce
- 2crowkis
- 3claude code · agents
- 4services
- 5your LLM provider
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.