Cache & sessions
Take the load your database hates
Sessions, rate limits, feature flags, the hot row every request reads. They are in Postgres in most applications, and they are the rows getting hammered — not because a database is bad at them, but because they were never questions. You already know the key.
Why this fits
Every one of these has the same shape: a key you already hold, a small value, and a lifetime. kevy does the lookup in O(1), expires the key itself without a cron job, and does several million of them a second on one machine.
The part people underrate is the expiry. A cache built on a database needs a sweeper, and the sweeper is where the bugs live. Here the engine drops the key when its time is up, whether or not anyone asks for it.
How
# a session that cleans itself up
SET session:7f3a '{"user":"ada","role":"admin"}' EX 3600
GET session:7f3a
TTL session:7f3a -> 3599
# a rate limit: one counter per client, expiring on a window
INCR rate:203.0.113.7 -> 1
EXPIRE rate:203.0.113.7 60
INCR rate:203.0.113.7 -> 2 (the window survives)
# feature flags: read constantly, written rarely, joined never
HSET flags new-checkout on dark-mode on beta-search off
HGET flags new-checkout -> "on"
HGETALL flags
# a cached row, invalidated by the writer rather than by a timer
SET user:881 "$json" EX 300
DEL user:881 # after you write to PostgresA cache is a second copy of the truth, and it can be wrong. kevy does not solve that — nothing does. Invalidate on write, not on a timer, and keep the TTL as a backstop rather than as the plan. And note that a multi-key MSET or DEL is atomic only within one shard: if two keys must change together, co-locate them with a {hashtag}.