Caching & Rate Limiting
Pluggable cache and API rate-limiting backends — memory for single instances, Redis for production at scale.
Overview
SiteKnock includes a cache abstraction and API rate limiting. Both support an in-memory backend for development and single-instance deployments, and Redis for shared state across multiple replicas.
Caching
"cache": {
"provider": "redis", // "memory" | "redis"
"ttlMs": 300000, // 5 minutes
"prefix": "my-app:cache"
}
| Backend | Use case |
|---|---|
| Memory | In-process; fine for dev and single-replica production |
| Redis | Shared across replicas; required for multi-instance production |
import { cache } from "@siteknock/cache"
await cache.set("key", value, { ttl: 60000 })
const value = await cache.get("key")
Rate limiting
"rateLimit": {
"provider": "redis", // "memory" | "redis"
"windowMs": 10000, // 10-second window
"limit": 200, // requests per window
"prefix": "my-app:api"
}
Rate limiting applies to all /api/* routes. In development it's automatically bypassed for friction-free iteration; in production, use Redis for accurate shared limiting across replicas.
Custom limits per route
import { rateLimit } from "@siteknock/rate-limit"
router.post("/expensive", rateLimit({ windowMs: 60000, limit: 10 }), handler)
Production recommendation
When you run more than one backend replica, use Redis for both cache and rate limiting so state is shared. Configure with CACHE_PROVIDER=redis and RATE_LIMIT_PROVIDER=redis.
Next steps
Was this page helpful?