DEV Community: Syed Ahmed Ali

How I Used Redis to Stop My Football Web App From Hammering the Database

Syed Ahmed Ali — Sun, 21 Jun 2026 14:54:23 +0000

A practical walkthrough of the cache-aside pattern — why it exists, how to implement it, and what breaks if you skip it.

When I built Flacron Gamezone, one of the first questions I had to answer wasn't about the UI or the API design. It was simpler and more uncomfortable than that: what happens when fifty users refresh the live scores page at the same time?

The honest answer, without caching, is that all fifty of them hit the database. And then the next fifty do the same. And the one after that. For a football platform where the data changes every few minutes but gets read thousands of times between those changes, that's a lot of identical queries doing identical work for no reason.

This is the problem Redis solves. More specifically, it's the problem the cache-aside pattern solves. Here's how I implemented it, what it looks like in production, and why the details matter.

Why Not Just Cache Everything?

Before getting into implementation, it's worth being honest about the tradeoff you're making when you add a cache.

Every cached value is a bet: you're betting that serving slightly stale data is better than the cost of hitting the database every time. For most data on most applications, that bet is obviously correct. But there are places where it isn't — user account data, payment state, anything where correctness matters more than speed.

On Flacron Gamezone, the split was clear:

Live match data — read constantly, changes infrequently, perfect for caching
User subscription status — hits Stripe and the database, should never be stale
Authentication tokens — never cached, always verified fresh

Getting this split right before you write a single line of caching code matters more than any implementation detail.

The Cache-Aside Pattern

Cache-aside (also called lazy loading) is the most common caching strategy, and for good reason — it's simple, it's predictable, and it fails gracefully.

The logic on every read request is:

Check the cache first
If the value is there (cache hit), return it
If it's not (cache miss), fetch from the database, store it in the cache, then return it

That's it. The cache only gets populated with data that's actually been requested. You're not pre-loading anything speculatively.

Here's what this looks like in code, in the context of the match service:

// services/matchService.ts

import { redis } from "../lib/redis";
import { matchRepository } from "../repositories/matchRepository";

const CACHE_TTL_SECONDS = 60; // 1 minute for live match data

export async function getLiveMatches(): Promise<Match[]> {
  const cacheKey = "matches:live";

  // Step 1: Check the cache
  const cached = await redis.get(cacheKey);
  if (cached) {
    return JSON.parse(cached);
  }

  // Step 2: Cache miss — fetch from database
  const matches = await matchRepository.findLive();

  // Step 3: Store in cache with TTL, then return
  await redis.set(cacheKey, JSON.stringify(matches), "EX", CACHE_TTL_SECONDS);

  return matches;
}

Clean, readable, and the logic is entirely self-contained in the service layer. The controller doesn't know caching exists. The repository doesn't know either. That separation matters when you need to change the caching strategy later.

Setting Up the Redis Client

I'm using Upstash for Redis in production — it's serverless, has a generous free tier, and works well with Vercel deployments. Locally, I run Redis via Docker.

// lib/redis.ts

import { Redis } from "@upstash/redis";

export const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL!,
  token: process.env.UPSTASH_REDIS_REST_TOKEN!,
});

One thing worth noting: Upstash uses an HTTP-based client (@upstash/redis), not the traditional ioredis TCP connection. For serverless environments, this is actually the correct choice — TCP connections don't survive the stateless nature of serverless functions well. If you're running a persistent Express server (not serverless), ioredis is the standard option.

Cache Invalidation: The Hard Part

There's a famous saying in computer science: "There are only two hard things: cache invalidation and naming things." It's a cliché because it's true.

Cache-aside with a TTL handles the simple case automatically — the cache entry expires after 60 seconds, and the next request repopulates it. For live match scores, this is acceptable. A one-minute lag in a score update isn't a product failure.

But for data that changes on user action — like when an admin updates match details — waiting for TTL expiry isn't good enough. You need active invalidation.

// services/matchService.ts

export async function updateMatch(id: string, data: Partial<Match>): Promise<Match> {
  const updated = await matchRepository.update(id, data);

  // Invalidate related cache keys immediately after a write
  await redis.del("matches:live");
  await redis.del(`match:${id}`);

  return updated;
}

The rule I follow: every write operation that could affect a cached read should also delete those cache keys. The next read will repopulate the cache with fresh data automatically. You're not managing the cache value directly — you're just telling it to forget what it knows.

Handling Cache Failures Gracefully

Here's something tutorials almost never cover: what happens when Redis goes down?

If your application throws an unhandled error every time the cache is unavailable, you've traded a performance problem for an availability problem. The whole point of a cache is to be an optimization, not a dependency.

The fix is straightforward — wrap cache operations in try/catch and fall through to the database on failure:

export async function getLiveMatches(): Promise<Match[]> {
  const cacheKey = "matches:live";

  try {
    const cached = await redis.get(cacheKey);
    if (cached) {
      return JSON.parse(cached);
    }
  } catch (err) {
    // Redis is unavailable — log it, but don't crash
    console.error("Cache read failed, falling back to DB:", err);
  }

  const matches = await matchRepository.findLive();

  try {
    await redis.set(cacheKey, JSON.stringify(matches), "EX", CACHE_TTL_SECONDS);
  } catch (err) {
    // Cache write failed — still return the data
    console.error("Cache write failed:", err);
  }

  return matches;
}

Your app is slower when Redis is down. It is not broken. That's the correct behavior.

What the Numbers Actually Look Like

Before caching, every request to the live matches endpoint was a database query. On a day with multiple live matches and active users, that's potentially hundreds of queries per minute for data that changes once every sixty seconds.

After caching, the database sees one query per minute for live match data regardless of traffic. Everything else is served from memory in under a millisecond. That's not a marginal improvement — it's a fundamentally different load profile.

The TTL is the lever you control. Lower it and your data is fresher but your cache hit rate drops. Raise it and your hit rate improves but stale data becomes more of a risk. For Flacron Gamezone, 60 seconds was the right balance. For a financial dashboard, you'd probably drop it to 5 or 10. For a product catalog that rarely changes, you might go hours.

What I'd Do Differently

One thing I got wrong early on was using overly broad cache keys. I had a single matches:all key that cached the entire match list. The moment I added pagination, that key became useless — the cached value was always the wrong page.

The right approach is to build cache keys that reflect exactly what was queried:

const cacheKey = `matches:status:${status}:page:${page}:limit:${limit}`;

More keys means more cache entries to manage and invalidate, but it also means your cache is actually useful across different query shapes. The tradeoff is worth it.

Summary

The cache-aside pattern is three steps: check the cache, miss to the database, write back. The important decisions are around which data to cache, what TTL makes sense for your use case, how to invalidate on writes, and how to handle cache failures without taking down your application.

None of this requires a complex setup. A single Redis client, one utility function, and consistent discipline about where caching logic lives in your service layer is enough to meaningfully change how your backend performs under load.

Flacron Gamezone is live at flacrongamezone.com. If you're building a backend and want a developer who thinks about these problems before they become production incidents, reach me at syedahmedali.com.

The Next.js Data Cache Error That Broke My Production App (And How I Fixed It)

Syed Ahmed Ali — Sun, 14 Jun 2026 12:27:49 +0000

The Next.js Data Cache Error That Broke My Production App (And How I Fixed It)

A real bug from building Flacron Gamezone — a live football platform built on Next.js 14 App Router.

There's a particular kind of bug that only shows up in production. Not because your environment variables are wrong or your build config is off — but because the framework is doing exactly what it was designed to do, and that design doesn't match what you assumed.

This is the story of one of those bugs.

The Setup

Flacron Gamezone is a live football match discovery platform. The matches page lists upcoming and live games, paginated, with filters. Simple enough on the surface.

The data fetching was originally done server-side. A server component would call a helper function — apiGet() — which internally called fetch() and returned the parsed JSON. The page rendered on the server, data included, and everything worked locally.

Then we deployed.

The Error

In production, the matches page started throwing a cryptic error after the first load:

Error: Dynamic server usage: Page couldn't be rendered statically because it used `headers`

Or sometimes, depending on the Next.js version and the exact request path:

Error: Cannot read properties of undefined (reading 'data')

What made it worse: it was intermittent. Refresh the page five times and it worked four of them. That kind of flakiness is the hardest to debug because it makes you doubt whether the bug is even real.

What Was Actually Happening

Next.js App Router has a built-in data cache. When you call fetch() inside a server component, Next.js caches that response by default — across requests, not just within a single render.

The problem: our apiGet() helper wasn't setting cache: "no-store". So Next.js was caching the first response and serving that cached data on subsequent requests — even when the underlying data had changed.

For a football platform showing live scores, stale cached data isn't just a bug. It's the whole product being wrong.

But there was a second problem layered on top. The server component was trying to read paginated data based on URL search params (?page=2, ?status=live). In some rendering paths, Next.js couldn't statically analyze those dynamic dependencies cleanly — especially when combined with the caching behavior. That's where the Dynamic server usage error was coming from.

The two issues were compounding each other.

What I Tried First (That Didn't Work)

The first instinct was to just add cache: "no-store" to the fetch calls inside apiGet().

const res = await fetch(url, { cache: "no-store" });

That fixed the stale data problem. But the intermittent render error on dynamic params persisted. The server component was still trying to read searchParams in a way that conflicted with how App Router handles static vs dynamic rendering.

I also tried wrapping the page in export const dynamic = "force-dynamic". That made the error go away — but it also meant the entire page was fully server-rendered on every request with no caching benefit at all. For a page with pagination and filters, that felt like giving up rather than solving the problem.

The Actual Fix: Move Pagination to the Client

The real solution was rethinking where the data fetching happened.

The matches listing didn't need to be a server-rendered data fetch at all. The page shell — the layout, the filters UI, the heading — could render on the server. But the paginated match data should be fetched client-side, on demand, triggered by the user's current page and filter state.

Here's what the refactored approach looked like:

Before (server component fetching paginated data):

// app/matches/page.tsx
export default async function MatchesPage({
  searchParams,
}: {
  searchParams: { page?: string; status?: string };
}) {
  const page = Number(searchParams.page) || 1;
  const data = await apiGet(`/matches?page=${page}&status=${searchParams.status}`);

  return <MatchList matches={data.matches} total={data.total} />;
}

After (client component fetching on state change):

// app/matches/page.tsx — server component, renders the shell
export default function MatchesPage() {
  return <MatchesClient />;
}

// components/MatchesClient.tsx — "use client"
"use client";

import { useState, useEffect } from "react";

export default function MatchesClient() {
  const [page, setPage] = useState(1);
  const [status, setStatus] = useState("all");
  const [matches, setMatches] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const fetchMatches = async () => {
      setLoading(true);
      const res = await fetch(
        `${process.env.NEXT_PUBLIC_API_BASE}/matches?page=${page}&status=${status}`,
        { cache: "no-store" }
      );
      const data = await res.json();
      setMatches(data.matches);
      setLoading(false);
    };

    fetchMatches();
  }, [page, status]);

  return (
    // render matches, pagination controls, filter buttons
  );
}

The key changes:

The server component becomes a thin shell that renders the client component. No data fetching, no dynamic param reading.
The client component owns the pagination and filter state via useState.
useEffect re-fetches whenever page or status changes — cleanly, predictably, with no caching issues because we control the fetch directly.
cache: "no-store" is explicit on every fetch. No surprises.

Why This Is Actually the Right Model for This Feature

It's tempting to feel like moving data fetching to the client is "giving up" on the server-side rendering benefits of App Router. But that framing misses the point.

Server components are excellent for data that's:

Known at request time
Not dependent on user interaction state
Appropriate to cache (even briefly)

Paginated, filterable, user-driven listings are none of those things. The user's current page and filter selection is the state. It changes constantly. Trying to drive that from the server via URL params creates exactly the kind of rendering ambiguity that caused this bug.

Client-side fetching for interactive, stateful UI isn't a fallback. It's the correct tool.

The Broader Lesson

Next.js App Router is powerful, but it has opinions. It will cache your fetch calls unless you tell it not to. It will try to statically optimize your pages unless you tell it they're dynamic. When those defaults conflict with what your feature actually needs, you don't fight the framework — you understand what it's trying to do and work with the model it's designed around.

In this case, the model is clear: server components for stable, cacheable data. Client components for interactive, user-driven state. The bug was the framework telling me I'd put the logic in the wrong place.

Summary

Problem	Root Cause	Fix
Stale data in production	`fetch()` cached by default in App Router	Add `cache: "no-store"` explicitly
Dynamic server usage error	Server component reading search params with conflicting cache behavior	Move paginated fetching to a `"use client"` component with `useState` + `useEffect`
Intermittent failures	Both issues compounding each other	Refactor to client-side paginated fetching entirely

If you're building on Next.js 14 App Router and hitting intermittent cache-related errors on pages with dynamic params — check where your fetch calls live and who owns the state. The answer is usually in the split between server and client, not in your network or your API.

Ahmed Ali is a Full-Stack Developer based in Pakistan, building production-ready web apps with Next.js, Node.js, PostgreSQL, and TypeScript. Flacron Gamezone is live at flacrongamezone.com. Reach me at syedahmedali.com.

How I Built a Live Football Platform That Doesn't Fall Apart Under Load

Syed Ahmed Ali — Sun, 31 May 2026 09:33:11 +0000

A walkthrough of the architecture decisions behind Flacron Gamezone a production full-stack app built with Next.js, Express, PostgreSQL, and Redis.

When a client approached me to build a live football match discovery platform, the requirements sounded straightforward on the surface: show live scores, let users subscribe, handle authentication. But the moment you start thinking about how those pieces connect in production, straightforward gets complicated fast.

This is the story of how I designed the backend for Flacron Gamezone — what decisions I made, why I made them, and what broke along the way.

The Problem With "Just Building It"
The Architecture: Four Distinct Layers
Why This Matters to a Client
The Bug That Taught Me Something Real
The Full Stack at a Glance
What I'd Do Differently

The Problem With "Just Building It"

The easiest version of this app is a single Express file: one route handler that queries the database, formats the data, and sends a response. I've seen this pattern in tutorials everywhere. It works for demos. It falls apart in production.

The problems are predictable: you can't test business logic without hitting the database, a change in one feature quietly breaks another, and the moment a second developer joins the codebase, nobody knows where anything lives.

I wanted to build something I could actually be proud to show an employer or a client. That meant committing to a proper layered architecture from day one, even on a project this size.

The Architecture: Four Distinct Layers

The entire Express backend is organized into four layers. Each layer has one job and talks only to the layer directly below it.

Route → Controller → Service → Repository

Here's what each one actually does.

Routes are just maps. They declare that POST /api/v1/subscriptions exists, attach the auth middleware, and hand off to the controller. No logic lives here.

Controllers handle the HTTP boundary. They extract data from req.body or req.params, call the appropriate service method, and send back a formatted response. They don't know anything about databases. They don't contain business rules. If a request comes in malformed, the controller catches it and returns a 400. That's the full extent of its responsibility.

Services are where the application logic lives. A SubscriptionService knows that before creating a subscription, it needs to verify the user doesn't already have one, call Stripe to create a customer, and only then persist the record. It coordinates between multiple repositories if needed. It throws typed errors that the controller can catch and translate into HTTP responses.

Repositories are the only layer that touches the database. A UserRepository has methods like findById, findByEmail, create. It uses Prisma under the hood. Nothing outside this layer writes a SQL query or touches a Prisma client directly.

The result is that when the client asked me to change how subscriptions were priced mid-project, I changed two methods in SubscriptionService and one in SubscriptionRepository. The routes, controllers, and every other service were completely untouched.

Why This Matters to a Client

If you're a client reading this: layered architecture means your project doesn't become unmaintainable the moment the original developer moves on. Any competent backend developer can read this codebase and understand where to make a change within minutes, not hours.

If you're an employer reading this: this is the pattern used in production systems at scale. The reason it's taught in enterprise codebases isn't bureaucracy — it's because the alternative is a system where nobody can safely change anything without breaking something else.

The Bug That Taught Me Something Real

Midway through development, Prisma started throwing connection timeout errors. Not consistently — just intermittently, and always on the first query after a cold start.

I spent an embarrassing amount of time checking my connection pool configuration, my .env file, my database credentials. Everything looked correct.

The actual problem: on Windows, localhost resolves to the IPv6 address ::1 before it tries IPv4 127.0.0.1. PostgreSQL, by default, listens on IPv4. Prisma was trying to connect to the IPv6 address, the connection was being refused, and the error message gave me no indication that address resolution was even involved.

The fix was a single character change in the database URL — replacing localhost with 127.0.0.1.

Before
DATABASE_URL="postgresql://user:pass@localhost:5432/flacron"
After
DATABASE_URL="postgresql://user:pass@127.0.0.1:5432/flacron"

I'm documenting this here because I found almost nothing about it when I was searching. If you're on Windows and Prisma is timing out on cold start, try this before you spend three hours reading connection pool documentation.

The Full Stack at a Glance

Frontend: Next.js 15 with App Router, deployed on Vercel
Backend: Express.js with the four-layer architecture described above
Database: PostgreSQL with Prisma ORM
Cache: Redis for live match data (cache-aside pattern, short TTL)
Payments: Stripe subscriptions with webhook verification
Auth: JWT access/refresh token pattern with role-based guards

Each piece was chosen deliberately. Redis sits in front of the live match queries specifically because that data is read far more often than it's written, and hitting the database on every poll request doesn't scale. Stripe handles payments because rolling your own payment processing is never the right call. PostgreSQL over MongoDB because this data is relational — users, subscriptions, and matches have hard dependencies between them that a document database makes awkward to enforce.

What I'd Do Differently

One thing I underestimated was how much time Stripe webhook handling would take to get right. Verifying the webhook signature, handling idempotency, making the handler resilient to duplicate events — each of those is its own small problem. I'd budget more time for that in future projects.

I'd also set up structured logging with Pino earlier. Console logs are fine locally. The first time you're debugging a production issue and you have no searchable, structured log trail, you feel it immediately.

The Live Project

Flacron Gamezone is live at flacrongamezone.com. The source code for the local development version is on GitHub.

If you're building something and want a developer who thinks about architecture before writing the first line of code, reach me at syedahmedali.com.

Ahmed Ali is a Full-Stack Developer based in Pakistan, building production-ready web apps and AI-powered SaaS products. Next.js · Node.js · PostgreSQL · Redis · TypeScript.

DEV Community: Syed Ahmed Ali

How I Used Redis to Stop My Football Web App From Hammering the Database

Why Not Just Cache Everything?

The Cache-Aside Pattern

Setting Up the Redis Client

Cache Invalidation: The Hard Part

Handling Cache Failures Gracefully

What the Numbers Actually Look Like

What I'd Do Differently

Summary

The Next.js Data Cache Error That Broke My Production App (And How I Fixed It)

The Next.js Data Cache Error That Broke My Production App (And How I Fixed It)

The Setup

The Error

What Was Actually Happening

What I Tried First (That Didn't Work)

The Actual Fix: Move Pagination to the Client

Why This Is Actually the Right Model for This Feature

The Broader Lesson

Summary

How I Built a Live Football Platform That Doesn't Fall Apart Under Load

Table of Contents

The Problem With "Just Building It"

The Architecture: Four Distinct Layers

Why This Matters to a Client

The Bug That Taught Me Something Real

The Full Stack at a Glance

What I'd Do Differently

The Live Project