Abin S Chandran

Posted on Aug 17 • Originally published at abinschandran.in

Building Node.js REST APIs That Scale to 50k+ Requests Per Second

#webdev #node #api #javascript

How I Build High-Performance Node.js REST APIs That Handle 50k+ Requests Per Second
published: true
description: A practical guide to building production-grade Node.js APIs using Express, Redis caching, PostgreSQL connection pooling, and load testing strategies.
tags: nodejs, javascript, webdev, api
canonical_url: https://www.abinschandran.in/blog/high-performance-nodejs-api

cover_image:

How I Build High-Performance Node.js REST APIs That Handle 50k+ Requests Per Second

By Abin S Chandran — Freelance Software Developer & Solution Architect, Kerala, India

After building production APIs for multiple SaaS platforms and startups, I've developed a repeatable architecture for Node.js REST APIs that consistently achieve 50,000+ requests per second under load testing without breaking a sweat.

In this post, I'll walk through the exact patterns I use — from project structure to Redis caching to PostgreSQL connection pooling.

The Stack

Node.js 20 LTS
Express.js 4.x
PostgreSQL 16 (with pgBouncer)
Redis 7 (for caching + rate limiting)
Docker + AWS ECS (deployment)

1. Project Structure That Scales

The biggest mistake I see in Node.js APIs is a flat structure that becomes unmaintainable at scale. Here's the structure I use on every project:

src/
├── config/          # Environment, DB, Redis config
├── controllers/     # Request handlers (thin layer)
├── services/        # Business logic (fat layer)
├── repositories/    # DB queries only (no logic)
├── middlewares/     # Auth, rate limit, validation
├── routes/          # Route definitions only
└── utils/           # Pure utility functions

The key insight: controllers are thin, services are fat, repositories are dumb.

Controllers only handle HTTP input/output. All business logic lives in services. Repositories only talk to the database.

2. Redis Caching — The 10x Multiplier

This single pattern will cut your database load by 80%:

// services/userService.js
const redis = require('../config/redis');
const userRepo = require('../repositories/userRepository');

const CACHE_TTL = 300; // 5 minutes

async function getUserById(userId) {
  const cacheKey = `user:${userId}`;

  // Try cache first
  const cached = await redis.get(cacheKey);
  if (cached) return JSON.parse(cached);

  // Cache miss — hit database
  const user = await userRepo.findById(userId);
  if (!user) return null;

  // Store in cache
  await redis.setex(cacheKey, CACHE_TTL, JSON.stringify(user));
  return user;
}

Cache invalidation rule: Always invalidate on write, never on read. When a user updates their profile, delete user:{userId} from Redis immediately.

3. PostgreSQL Connection Pooling

Never create a new DB connection per request. Always use a pool:

// config/database.js
const { Pool } = require('pg');

const pool = new Pool({
  host: process.env.DB_HOST,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  port: 5432,
  max: 20,                  // max connections in pool
  idleTimeoutMillis: 30000, // close idle connections after 30s
  connectionTimeoutMillis: 2000,
});

module.exports = pool;

For production, I put pgBouncer in front of PostgreSQL in transaction pooling mode — this alone can multiply your connection capacity by 10x.

4. Rate Limiting with Redis

Protect your API from abuse and DDoS without a third-party service:

// middlewares/rateLimiter.js
const redis = require('../config/redis');

function rateLimiter(limit = 100, windowMs = 60000) {
  return async (req, res, next) => {
    const key = `rl:${req.ip}`;
    const current = await redis.incr(key);

    if (current === 1) {
      await redis.pexpire(key, windowMs);
    }

    if (current > limit) {
      return res.status(429).json({ 
        error: 'Too many requests. Please try again later.' 
      });
    }

    res.setHeader('X-RateLimit-Remaining', limit - current);
    next();
  };
}

5. The Async Error Handler Wrapper

Stop writing try-catch in every controller:

// utils/asyncHandler.js
const asyncHandler = (fn) => (req, res, next) => {
  Promise.resolve(fn(req, res, next)).catch(next);
};

// Global error middleware
app.use((err, req, res, next) => {
  const status = err.status || 500;
  res.status(status).json({
    success: false,
    message: err.message || 'Internal server error',
  });
});

Now your controllers look clean:

router.get('/users/:id', asyncHandler(async (req, res) => {
  const user = await userService.getUserById(req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });
  res.json({ success: true, data: user });
}));

Results

With this stack on a $20/month AWS t3.small instance:

Throughput: 52,000 req/sec (Apache Bench, 100 concurrent)
P99 latency: < 12ms (cached responses)
P99 latency: < 45ms (database responses)
Error rate: 0.00% under normal load

What's Next?

In the next post, I'll cover how I add AI integration to this same API architecture — connecting OpenAI/Gemini endpoints with streaming responses, pgvector semantic search, and rate limiting for LLM calls.

I'm Abin S Chandran, a Freelance Software Developer & Solution Architect based in Kerala, India. I build production-grade web APIs, SaaS platforms, and Flutter mobile apps for startups and global clients.

Portfolio & Contact: abinschandran.in

DEV Community