Module 5 — Making It Survive Load

Your app is correct. Now make it survive being popular. This module applies System Design and the distributed rate limiter deep dive. We add three things, each targeting a different failure under load: a rate limiter (abuse), a cache (hot reads), and a background job (bursty writes).

Goal

• A rate limiter on write endpoints, backed by Redis so it works across multiple instances.
• A cache on the hot read (GET /s/:publicId for public snippets), with correct invalidation.
• The view-count increment moved off the request path into a background job.

Step 0: Add Redis

docker run --name snippets-redis -p 6379:6379 -d redis:7

Redis is the right tool here for the reason the data chapter gives: it's an in-memory store, so the central counter and the cache are microsecond operations, and it's shared across all your app instances — which is the whole point.

Step 1: A distributed rate limiter

A per-process in-memory counter is useless the moment you run two instances — each sees only its own slice of a client's traffic, so the real limit is N × your_limit. The deep dive's lesson: the counter must be central, and the increment must be atomic.

1. Key by client identity + window

   ratelimit:{userId}:{minute}. One key per user per time window.

2. Increment atomically, set expiry on first hit

   INCR returns the new count atomically — no check-then-set race even under concurrent requests. On the first increment, set the key to expire at the window's end so it cleans itself up.

3. Reject over the limit

   If the count exceeds the limit, return 429 Too Many Requests with a Retry-After header.

async function rateLimit(userId: number, limit = 60) {
  const key = `ratelimit:${userId}:${Math.floor(Date.now() / 60000)}`;
  const count = await redis.incr(key);
  if (count === 1) await redis.expire(key, 60); // window TTL on first hit
  if (count > limit) throw new HttpError(429, "rate_limited");
}

Step 2: Cache the hot read

When a snippet gets shared widely, GET /s/:publicId is hit thousands of times for the same unchanging data, each time querying Postgres. That's wasteful and it's how a viral link takes down your database. Cache it.

app.get("/s/:publicId", async (c) => {
  const id = c.req.param("publicId");
  const cacheKey = `snippet:${id}`;

  const cached = await redis.get(cacheKey);
  if (cached) {
    enqueueViewIncrement(id);              // still count the view (Step 3)
    return c.json(JSON.parse(cached));
  }

  const snippet = await getByPublicId(id);
  if (!snippet || !snippet.is_public) return c.json({ error: "not_found" }, 404);

  const response = toResponse(snippet);
  await redis.set(cacheKey, JSON.stringify(response), "EX", 300); // 5-min TTL
  enqueueViewIncrement(id);
  return c.json(response);
});

Step 3: Move the write off the request path

Notice the view counter. Incrementing view_count on every read means every read is now also a write to Postgres — and a hot snippet generates a storm of writes to one row, which contend with each other and slow the read the user is waiting on. The fix: the user's read shouldn't wait on the counter at all. Increment it asynchronously.

For this build, a lightweight queue is enough: push view events to a Redis list (or increment a Redis counter views:{id}), and run a small worker on an interval that drains them into Postgres in a batch.

// fire-and-forget on the read path
function enqueueViewIncrement(publicId: string) {
  redis.incr(`views:${publicId}`).catch(() => {}); // best-effort, never blocks the read
}

// background worker, every 10s: drain the Redis counters into Postgres in one batch
async function flushViews() {
  const keys = await redis.keys("views:*");
  for (const key of keys) {
    const n = Number(await redis.getdel(key));   // read + clear atomically
    if (n > 0) await pool.query(
      `update snippets set view_count = view_count + $1 where public_id = $2`,
      [n, key.slice("views:".length)]
    );
  }
}

Acceptance check

# rate limit: hammer create past the limit → eventually 429
for i in $(seq 1 70); do
  curl -s -o /dev/null -w "%{http_code}\n" -b jar.txt \
    -XPOST localhost:3000/snippets -H "Idempotency-Key: $(uuidgen)" -d '{"body":"x"}'
done | sort | uniq -c           # you should see some 201s and then 429s

# cache: GET a public snippet twice; the second is served from Redis
# (log a cache hit/miss to see it). Then edit it → next GET reflects the change.

# views: GET a snippet several times; within ~10s view_count climbs via the worker,
# and the GET latency didn't include the counter write.

You're done when writes get rate-limited to 429 past the threshold, a hot public read is served from cache and correctly reflects an edit (invalidation works), and the view count rises via the background worker without slowing the read. Commit it.