Back to Blog
backendredissystem-designnodejs

Redis Is the Only Infrastructure You Need (For Most Apps)

Message queues, real-time events, caching, rate limiting, sessions — Redis handles all of them. Stop over-engineering your stack.

March 5, 20267 min read

You don't need RabbitMQ. You don't need a separate WebSocket server. You don't need Memcached, Kafka, or a dedicated rate limiter. For small-to-medium apps, Redis does all of that.

The industry has a compulsive over-engineering problem. A startup with 100 users runs RabbitMQ, Kafka, Elasticsearch, and Redis — when Redis alone could handle four of those use cases. Every added service means more infrastructure to monitor, more failure points, more operational cost. The right question isn't "what specialized tool should I use for this?" — it's "what can ONE tool handle before I need TWO?"

The Hidden Cost of Specialized Services

Every new service in your stack has a tax:

  • A message queue (RabbitMQ/Kafka) needs its own server, dashboard, dead letter queue configuration, and someone who understands AMQP
  • A dedicated WebSocket server needs sticky sessions, connection tracking, and horizontal scaling coordination
  • Memcached alongside Redis means two caching layers, two connection pools, two things to get paged at 3am for

Most small-to-medium apps never reach the scale that justifies these dedicated services. If you have fewer than 10,000 concurrent users and fewer than 1,000 messages/second, Redis handles everything in this post comfortably.

Let's go through each use case.

Replace RabbitMQ: Redis as a Message Queue

Redis gives you two options for job queues.

Redis Lists (LPUSH/BRPOP) work for simple fire-and-forget jobs. Push to the tail, pop from the head — it's a queue. No persistence guarantees, but for non-critical work it's fine.

Redis Streams (XADD/XREADGROUP) are the serious option. Persistent, consumer-group support, message acknowledgment — it's the closest Redis gets to Kafka or RabbitMQ. For most apps, it's more than enough.

In Node.js, BullMQ wraps Redis Streams into a production-ready queue with retries, backoff, priority, and a UI dashboard:

import { Queue, Worker } from 'bullmq'
import { Redis } from 'ioredis'

const connection = new Redis({ host: 'localhost', port: 6379 })

// Producer — any service can push jobs
const emailQueue = new Queue('emails', { connection })

await emailQueue.add('welcome', {
  userId: '123',
  template: 'welcome-email',
})

// Consumer — processes jobs concurrently
const worker = new Worker(
  'emails',
  async (job) => {
    await sendEmail(job.data.userId, job.data.template)
  },
  { connection, concurrency: 5 },
)

worker.on('failed', (job, err) => {
  console.error(`Job ${job?.id} failed:`, err)
})

BullMQ handles retries, delayed jobs, cron-like repeatable jobs, and rate-limited queues. You get all of this without running a single RabbitMQ broker.

When Redis breaks down here: millions of messages per second, complex topic-based routing (RabbitMQ's exchange/binding model), or strict multi-language consumer requirements. At that scale, RabbitMQ or Kafka earn their place.

Replace Socket.io Scaling Layer: Redis Pub/Sub

Redis Pub/Sub lets any number of subscribers receive messages published to a channel. For real-time features — notifications, live dashboards, chat — it's the message bus that ties your services together.

import { Redis } from 'ioredis'

const pub = new Redis()
const sub = new Redis()

// Publisher — any service, any server
await pub.publish(
  'notifications',
  JSON.stringify({
    userId: '123',
    message: 'Someone commented on your post',
    type: 'comment',
  }),
)

// Subscriber — your WebSocket or SSE endpoint
sub.subscribe('notifications')

sub.on('message', (channel, message) => {
  const data = JSON.parse(message)
  // Push to connected clients via WebSocket or SSE
  sendToUser(data.userId, data)
})

This pattern is especially powerful when you scale horizontally. Multiple app instances can all subscribe to the same channel — Redis is the shared backbone. In fact, Socket.io's official scaling solution (@socket.io/redis-adapter) uses exactly this under the hood. Even when you use Socket.io, Redis is doing the real work.

When Redis breaks down here: Pub/Sub is fire-and-forget — if a subscriber goes down, it misses messages. For durability and replay, use Redis Streams or Kafka.

Replace Memcached: Redis as a Cache

The most obvious use case, but it's worth saying explicitly: there is almost no reason to run Memcached alongside Redis. Redis is a strict superset of Memcached's functionality.

async function getUserProfile(userId: string) {
  const cacheKey = `user:${userId}:profile`

  const cached = await redis.get(cacheKey)
  if (cached) return JSON.parse(cached)

  const profile = await db.users.findById(userId)
  await redis.set(cacheKey, JSON.stringify(profile), 'EX', 300) // 5-min TTL

  return profile
}

For structured caching, use Redis Hashes (HSET/HGET) to store and retrieve individual fields without deserializing the entire object. For lists of IDs (e.g., a user's recent posts), use Redis Lists or Sorted Sets. The right data structure matters for both performance and TTL granularity.

Replace Dedicated Rate Limiters: Redis + INCR

A fixed-window rate limiter fits in five lines:

async function rateLimit(
  key: string,
  limit: number,
  windowSec: number,
): Promise<boolean> {
  const current = await redis.incr(key)
  if (current === 1) await redis.expire(key, windowSec)
  return current <= limit
}

// In your middleware
const allowed = await rateLimit(`rate:${req.ip}`, 100, 60) // 100 req/min per IP
if (!allowed) return res.status(429).json({ error: 'Too many requests' })

For a sliding window with more precision, use Sorted Sets:

async function slidingWindowRateLimit(
  key: string,
  limit: number,
  windowMs: number,
): Promise<boolean> {
  const now = Date.now()
  const windowStart = now - windowMs

  const pipeline = redis.pipeline()
  pipeline.zremrangebyscore(key, '-inf', windowStart)
  pipeline.zadd(key, now, `${now}-${Math.random()}`)
  pipeline.zcard(key)
  pipeline.expire(key, Math.ceil(windowMs / 1000))

  const results = await pipeline.exec()
  const count = results?.[2]?.[1] as number

  return count <= limit
}

No separate service, no added dependency — just Redis.

Replace Database Sessions: Redis Session Storage

Sessions stored in a database require a query on every request. Sessions in Redis are sub-millisecond reads with automatic expiry via TTL.

import session from 'express-session'
import RedisStore from 'connect-redis'
import { Redis } from 'ioredis'

const redis = new Redis()

app.use(
  session({
    store: new RedisStore({ client: redis }),
    secret: process.env.SESSION_SECRET!,
    resave: false,
    saveUninitialized: false,
    cookie: {
      maxAge: 86400000, // 24 hours
      httpOnly: true,
      secure: process.env.NODE_ENV === 'production',
    },
  }),
)

Any server in your cluster can read any session — no sticky sessions needed. When the TTL expires, Redis cleans up automatically.

Bonus: Replace Custom Leaderboards with Redis Sorted Sets

Sorted Sets are Redis's killer data structure for rankings. Each member has a score; ZADD, ZINCRBY, and ZREVRANGE give you a real-time leaderboard in O(log N):

// Add points when a user completes an action
await redis.zincrby('leaderboard:weekly', 50, `user:${userId}`)

// Fetch top 10 with scores
const top10 = await redis.zrevrange('leaderboard:weekly', 0, 9, 'WITHSCORES')

// Get a specific user's rank (0-indexed)
const rank = await redis.zrevrank('leaderboard:weekly', `user:${userId}`)

Building this in PostgreSQL requires a window function query, an index on the score column, and careful cache invalidation. In Redis it's three commands.

When Redis Genuinely Isn't Enough

Be honest about the limits. Redis is not the right tool when:

  • Data exceeds available RAM. Redis is in-memory by design. If your working dataset doesn't fit in RAM, you need a database.
  • You need complex queries. No SQL, no JOINs, no GROUP BY. Redis is not an analytics engine.
  • You need strong durability guarantees. Pub/Sub is fire-and-forget. Streams are better but not at Kafka's durability level.
  • Extreme throughput. Millions of messages per second with strict ordering across partitions — that's Kafka's domain.
  • Complex message routing. RabbitMQ's topic exchanges and header-based routing have no equivalent in Redis.

The honest threshold: if you're processing fewer than 1,000 messages/sec and have fewer than 10,000 concurrent users, Redis handles everything above without breaking a sweat.

One Tool, Five Problems

The best architecture isn't the one with the most services — it's the one with the fewest services that still works.

Redis replaces:

  • RabbitMQ → Redis Streams / BullMQ
  • Socket.io scaling layer → Pub/Sub
  • Memcached → String/Hash caching with TTL
  • Dedicated rate limiter → INCR + EXPIRE / Sorted Sets
  • Database sessions → RedisStore with automatic TTL

Start here. Add specialized services only when Redis tells you through metrics — latency, memory pressure, throughput limits — not through assumptions. Most apps never reach that point.

This post was written with the assistance of AI to help articulate the author's own views, knowledge, and experiences.

Back to Blog