Redis store

import Redis from 'ioredis';
import {
  Algorithms,
  createRateLimiter,
  RedisStore,
} from 'limix';

const redis = new Redis(process.env.REDIS_URL);
const store = new RedisStore(redis, { keyPrefix: 'billing-api' });

const limiter = createRateLimiter({
  algorithm: Algorithms.FIXED_WINDOW,
  limit: 100,
  windowMs: 60_000,
  store,
});

Redis-backed decisions execute atomically — each decision runs as a single Lua script, timed using Redis’s own clock rather than the application host’s, so clock drift between application instances can’t affect enforcement. Reuse the Redis connection and close it during your application’s normal shutdown sequence.

Key isolation

Every key RedisStore writes is scoped by keyPrefix (default "limix"), the algorithm, the limit, and the window — plus a hashed identifier. This means:

• Different apps sharing one Redis database won’t collide, as long as they use different prefixes.
• Different algorithms or differently configured limiters using the same identifier never collide with each other, even under the same prefix.

Give independently enforced policies with otherwise identical settings their own keyPrefix if they should be tracked separately.

Failure policy

Decide whether your endpoint should fail open or fail closed before production. The appropriate choice differs between a login endpoint and a low-risk public feed. Store failures (a bad connection, a malformed response) surface as a catchable RateLimiterStoreError with a stable code, rather than a raw client exception, so you can branch on them deliberately instead of guessing at the shape of whatever the Redis client throws.