GET handlers consider stale-while-revalidate caching

GET routes that return the same data on every request — product listings, published posts, public user profiles — without any caching strategy convert every user visit into a full database round-trip. At modest scale this is waste; at traffic spikes it is the mechanism by which a popular moment becomes a database overload event. Even a 60-second stale-while-revalidate cache cuts database load by roughly 100x for a route that serves one request per second, while keeping data within a minute of fresh. OWASP LLM10 (Unbounded Consumption) identifies uncached expensive operations as a key cost amplification vector — the same logic applies to database-backed GET routes that serve identical responses to many users.

Add Cache-Control: public, s-maxage=60, stale-while-revalidate=300 to read-only GET routes that serve public data. In a Next.js Route Handler:

export async function GET() {
  const posts = await prisma.post.findMany({
    where: { published: true },
    orderBy: { publishedAt: 'desc' },
    take: 20,
  })
  return Response.json(posts, {
    headers: {
      'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=300',
    },
  })
}

Alternatively, export revalidate = 60 at the route segment level to use Next.js's built-in ISR. Reserve cache: 'no-store' for routes that return user-specific or time-critical data. Document the caching intent with a comment so future developers know the omission is intentional when it is.