Online shops
Product pages, prices and stock levels are read thousands of times per second and refreshed by tag when the catalog changes.
Core dataPerformance
Caching
Keep your hottest data in memory and answer reads in well under a millisecond, on an engine that puts every core to work.
- GET/s pipelined, measured
- 36.6M
- TTL precision
- ns
- existing clients work
- RESP2/3
Step 1 of 5
Read through the cache
A hit comes straight back from memory. The database is not touched.
Example sessionplaying
# Read through the cache
hotkv> GET product:1001
"{\"name\":\"Desk lamp\",\"price\":39}"
An animated walkthrough with real HotKV commands and example replies. Click any step to jump to it.
The problem
Databases are slow and expensive to hit for data that is read thousands of times a second. Every page view, API call or dashboard refresh repeats the same query, and the database becomes the bottleneck long before your application does.
How HotKV handles it
HotKV sits in front of the database and holds results in memory. Your application reads from HotKV first and only falls back to the database on a miss. Because HotKV runs commands on many threads at once, a busy cache does not funnel every client through a single core, and tags let you invalidate a whole group of entries when the underlying data changes.
Step by step
What happens, command by command
- 01
Read through the cache
A hit comes straight back from memory. The database is not touched.
GET product:1001 - 02
Miss, so load once and cache it
On a miss the application reads the database once and caches the result for five minutes.
SET product:2002 "{\"name\":\"Oak desk\",\"price\":420}" EX 300 - 03
Tag entries by what they depend on
Every cached page that shows lighting products carries the same tag.
TAG.SET product:1001 catalog:lighting - 04
Invalidate the group
Prices changed. List every key with the tag and delete them in one pipeline.
TAG.MEMBERS catalog:lighting - 05
Very short-lived entries
A flash token, already set, that must vanish after 250 ms, with nanosecond precision.
NEXPIRE flash:token:9 250000000
Where it fits
Real-world scenarios
APIs and mobile backends
Responses for popular endpoints are cached with short TTLs, so traffic spikes hit memory instead of the database.
Content sites
Rendered fragments and article metadata are cached for minutes and invalidated by tag when an editor publishes.
Built in
What you get
TTLs from seconds to nanoseconds
EXPIRE and PEXPIRE work as you expect. NEXPIRE adds nanosecond precision.
EXPIREPEXPIRENEXPIREInvalidate by tag
Label keys with TAG.SET, then find every key with a label.
TAG.SETTAG.MEMBERSOptional compression
Large payloads can be compressed so more of your working set fits in memory.
Multi-threaded reads
Commands execute on parallel threads, so throughput grows with cores. Figures are on the Performance page.
GETMGETCommon questions
Can I use my existing Redis client?
HotKV speaks the Redis protocol (RESP2 and RESP3), so standard Redis clients connect to it. Check the command reference for the commands you rely on.
How do I invalidate a group of cached keys?
Tag the keys with TAG.SET when you cache them, then call TAG.MEMBERS and delete what comes back.
Where does the 36.6M figure come from?
It is the pipelined GET throughput from HotKV's published benchmark. The method and hardware are on the Performance page.
Related use cases
Try it on your own workload
HotKV speaks the Redis protocol, so you can point an existing client at it and run these same commands.