[Performance] Multi-Tenant Rate Limiting Design in Next.js API Gateway Using Upstash Redis

Preventing "Resource Contention" in B2B API Provisioning

When publishing and operating SaaS or internal API systems (API Gateways), preventing resource exhaustion due to unexpectedly large access volumes (traffic spikes, DoS attacks) from specific customers or integrated programs is an absolute requirement for stable operation.

Particularly in B2B systems, the following challenges arise:

1. API Monopolization by a Specific Tenant: A data synchronization script for one company falls into an infinite loop due to a bug, continually hitting the API thousands of times per second, resulting in extremely slow connections for all other clients.
2. The Noisy Neighbor Problem: In a multi-tenant environment, the access load of other tenants adversely affects the overall performance of your system.
3. Evaluation Overhead: If the rate limiting (request frequency restriction) check process itself is heavy, the original API response speed (latency) drops significantly.

To resolve these issues, we implement a fast and highly reliable rate-limiting gateway using Next.js Edge Middleware (which executes processes on global servers geographically close to the customer) and Upstash Redis, a serverless solution capable of sub-millisecond access evaluation.

---

2. Before & After: Resolving the Challenges

Item	Traditional DB (SQL) Checks (Before)	Next.js Edge Middleware + Upstash Redis (After)
Evaluation Latency	50ms–200ms (Query execution to DB)	1ms–10ms (Atomic operations in in-memory Redis)
API Performance	DB connection pools are exhausted as simultaneous access increases	Scales endlessly as serverless Redis has no pool limits
Edge Runtime Support	Standard DB drivers do not work in Edge environments	Works on Edge using HTTP/REST-based Redis clients
Limit Configuration	Can only configure uniform settings across tenants	Individual limit values can be modified instantly via hash tables in Redis

---

3. Concrete Implementation Example: Sliding Window Rate Limiting

Here is an example of implementing tenant-specific limit checks in Next.js Edge Middleware using the official Upstash Redis rate limiting library @upstash/ratelimit.

Edge Middleware Code (middleware.ts)

import { NextRequest, NextResponse } from "next/server";
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

// Create an Upstash Redis instance
const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL!,
  token: process.env.UPSTASH_REDIS_REST_TOKEN!,
});

// Define the rate limiter for tenants:
// Allow a maximum of 100 requests within a 10-second window per API key
const ratelimit = new Ratelimit({
  redis: redis,
  limiter: Ratelimit.slidingWindow(100, "10 s"),
  analytics: true, // For access analytics in the dashboard
});

export async function middleware(request: NextRequest) {
  // Retrieve the API key (tenant identifier) from the request headers
  const apiKey = request.headers.get("x-api-key") || "anonymous";

  // Evaluate the limit based on the tenant key
  const { success, limit, reset, remaining } = await ratelimit.limit(
    `api_limit:${apiKey}`
  );

  if (!success) {
    return new NextResponse(
      JSON.stringify({
        error: "Too Many Requests",
        message: "API execution limit reached. Please wait a moment and try again.",
      }),
      {
        status: 429,
        headers: {
          "Content-Type": "application/json",
          "X-RateLimit-Limit": limit.toString(),
          "X-RateLimit-Remaining": remaining.toString(),
          "X-RateLimit-Reset": reset.toString(),
        },
      }
    );
  }

  // Pass the request through if successful
  const response = NextResponse.next();
  response.headers.set("X-RateLimit-Remaining", remaining.toString());
  return response;
}

// Apply middleware only to /api/ paths
export const config = {
  matcher: "/api/:path*",
};

---

4. HadayaLab's API Performance Design

HadayaLab provides the following traffic design and infrastructure integration services for companies that handle massive data integrations and API communications with external systems:

• API Rate Limiting Design: Selecting optimal algorithms that allow legitimate B2B users to connect without stress while preventing API abuse.
• Distributed Caching with Upstash Redis: Caching frequently accessed master data and product information at the edge to reduce backend DB load.
• Next.js Edge Rendering: A next-generation frontend architecture that balances page rendering speed with data security.

If you are an IT leader considering measures to improve API responses and prevent system outages during traffic spikes, please contact HadayaLab.