Use Case

Sub-millisecond reads for your hottest data

Your database handles reads fine at low traffic. But at scale, the same queries run thousands of times per second and things start falling over. Lux gives you a Redis-compatible cache layer backed by a multi-core Rust runtime and the same project surface as your app data.

The Problem

Your database handles reads fine at low traffic. But when you hit scale, the same queries run thousands of times per second and your database starts sweating. The answer is always a cache layer, but that means managing Redis, writing cache invalidation logic, handling cache stampedes, setting up monitoring, and dealing with a separate service that can go down. And if you are already using Redis for other things (queues, sessions), you are overloading one instance or managing multiple. Every cache key needs a TTL strategy. Every write needs invalidation logic. Every deployment needs Redis healthy or your app degrades. It is a lot of operational surface area for what should be a simple read optimization.

Without Lux

Self-managed Redis

Provision and maintain

Invalidation Logic

Custom cache busting

Monitoring Stack

Alerting and dashboards

Failover Config

Sentinel or cluster setup

4 concerns to manage before you cache a single key.

vs

With Lux

Just Lux

Cache + rate limit + sessions + queues

Same Redis-style commands. Multi-core engine. One project.

Getting Started

import { Lux } from "@luxdb/sdk"

const db = new Lux(process.env.LUX_DIRECT_URL ?? "lux://localhost:6379")

async function getUser(userId) {
  const cached = await db.get(`cache:user:${userId}`)
  if (cached) return JSON.parse(cached)

  const user = await fetchUserFromPrimaryDb(userId)
  await db.set(`cache:user:${userId}`, JSON.stringify(user), "EX", 300)
  return user
}

Classic cache-aside pattern. SET with EX for automatic TTL expiration.

How It Works

Lux gives you the Redis command surface with TTL support, atomic operations, and a multi-core Rust runtime. SET with EX for time-based expiration. INCR/EXPIRE for rate limiting. Hashes for structured cached objects. The command surface is the same Redis API you already know, so many cache workloads migrate by changing the connection string.

Under the hood, Lux's multi-threaded architecture lets independent cache operations use multiple CPU cores instead of bottlenecking on one command thread. In the published benchmark workload, pipelined SET reaches multi-million ops/sec and the gap grows with pipeline depth. Real numbers depend on value size, command mix, network path, persistence settings, and hardware.

Because Lux also handles your vectors, time series, and queues, you are not adding another service. Your cache layer is built into the same database you are already using for everything else. One connection string, one bill, one thing to monitor. When your cache and your job queue run on the same engine, there is no cross-service failure mode to worry about.

TTL expiration uses Lux's cached clock system, where the timestamp is captured once per read batch and reused across all commands. This means expired keys are cleaned up efficiently without the per-key syscall overhead that slows down traditional implementations. Set a TTL and forget about it.

Advanced Patterns

import { Lux } from "@luxdb/sdk"

const db = new Lux(process.env.LUX_DIRECT_URL ?? "lux://localhost:6379")

async function rateLimit(userId, limit = 100, windowSec = 60) {
  const key = `ratelimit:${userId}`
  const current = await db.incr(key)
  if (current === 1) await db.expire(key, windowSec)
  return current <= limit
}

async function cacheProduct(productId, data) {
  const key = `cache:product:${productId}`
  await db.hset(key, "name", data.name, "price", data.price, "stock", data.stock)
  await db.expire(key, 600)
}

const price = await db.hget("cache:product:42", "price")

async function warmCache(keys) {
  const pipeline = db.pipeline()
  for (const key of keys) {
    pipeline.get(`cache:${key}`)
  }
  return pipeline.exec()
}

Rate limiting with sliding windows, hash-based structured caching, pipeline-based cache warming.

Feature Deep-Dive

TTL Auto-Expiration

SET with EX, PX, EXAT, or PXAT for flexible expiration. Lux's cached clock system handles cleanup efficiently without per-key overhead. Set a TTL and the key disappears on schedule. No background jobs, no cron, no manual cleanup.

Atomic Operations

INCR, DECR, INCRBY, INCRBYFLOAT for lock-free counters. SETNX for distributed locks. GETSET for atomic swap. Every operation is safe under concurrent access without external locking. Rate limiters, counters, and semaphores work out of the box.

Zero Migration

Lux speaks the Redis protocol with 200+ commands supported. Use any Redis client library in any language. Point your connection string at Lux and your existing caching code works with zero changes. Same commands, faster engine.

Performance

12M

ops/sec measured SET throughput

<1ms

p99 read latency

200+

Redis commands supported

Star on GitHub