DEV Community: Abin S Chandran

Building Scalable Full-Stack Web Applications with Next.js 15, Node.js, and PostgreSQL

Abin S Chandran — Thu, 03 Sep 2026 08:31:04 +0000

Building Scalable Full-Stack Web Applications with Next.js 15, Node.js, and PostgreSQL

A production architecture blueprint covering React 19 Server Components, connection-pooled PostgreSQL with Drizzle/Prisma, asynchronous worker queues, and sub-10ms REST API design.

Originally published at abinschandran.in

Why Most Full-Stack Web Applications Fail to Scale

When startups and growing businesses launch their initial MVP, speed of delivery often takes precedence over architectural discipline. Teams frequently bundle complex business logic directly inside server action handlers, create unpooled database connections that crash under moderate concurrency, and fail to isolate long-running background tasks.

As user traffic scales beyond 1,000 concurrent requests, these shortcuts manifest as:

Database Connection Exhaustion: Serverless lambdas or auto-scaling Node instances creating thousands of open connections, locking PostgreSQL.
Degraded Core Web Vitals: Bloated client JavaScript bundles causing slow Largest Contentful Paint (LCP) and high Interaction to Next Paint (INP).
Brittle Third-Party Integrations: Synchronous Stripe, SMS, or email Webhooks blocking the HTTP event loop, resulting in 504 Gateway Timeouts.

In this architectural guide, I share the exact production blueprint I use as a Freelance Software Developer & Solution Architect to deliver resilient, sub-10ms web platforms for founders in Kerala, India, and worldwide.

1. The Tri-Tier Architecture Model

To maintain high performance and clean maintainability, we separate the system into three distinct responsibility tiers:

┌─────────────────────────────────────────────────────────────┐
│                   Presentation & SSR Tier                   │
│         Next.js 15 App Router + React 19 Server Components  │
└──────────────────────────────┬──────────────────────────────┘
                               │ HTTPS / JSON RPC
┌──────────────────────────────▼──────────────────────────────┐
│                    API & Compute Engine                     │
│    Node.js + Express / NestJS + BullMQ Redis Task Worker    │
└──────────────────────────────┬──────────────────────────────┘
                               │ Pooled TCP / Sub-5ms
┌──────────────────────────────▼──────────────────────────────┐
│                   Persistence & Search Layer                │
│    PostgreSQL (pgBouncer) + Redis Cache + pgvector Search   │
└─────────────────────────────────────────────────────────────┘

Presentation Tier (Next.js 15 App Router): Responsible strictly for rendering UI, streaming HTML with React Server Components (RSC), and validating client input. Zero heavy relational database joins happen in client bundle components.
API & Business Logic Tier (Node.js & Express): Dedicated, clustered Node.js microservices handling core business transactions, role-based JWT authentication, rate limiting, and webhook validation.
Data & Queue Tier (PostgreSQL + Redis): Relational data integrity guarded by connection pooling (pgBouncer) and asynchronous task offloading via Redis.

2. Eliminating Database Bottlenecks with Connection Pooling

PostgreSQL allocates a dedicated backend OS process for each incoming client connection, consuming ~5–10 MB of RAM per connection. In dynamic serverless or auto-scaling container environments, spawning 200 concurrent requests can easily saturate Postgres connection limits.

Production Configuration:

Use pgBouncer in transaction pooling mode.
In Node.js / TypeScript, configure your connection pool with conservative maximum limits:

import { Pool } from 'pg';

// Optimized connection pool for production Node.js workloads
export const dbPool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 20, // Max concurrent clients in the pool
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000,
  maxUses: 7500, // Recycle connection to prevent driver memory leaks
});

Composite Indexing for Sub-10ms Query Response:

Always back foreign keys and filtered timestamp ranges with composite B-Tree indexes:

-- Accelerate tenant dashboard telemetry queries
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_orders_tenant_created 
ON orders (tenant_id, created_at DESC) 
INCLUDE (total_amount, status);

3. Asynchronous Worker Pipelines with BullMQ & Redis

Synchronous API execution is the number one cause of server crashes during traffic spikes. If a user action requires sending a confirmation email, generating an invoice PDF, or syncing with an external CRM, never execute it within the client request cycle.

Push the job payload to a Redis queue and return an instant 202 Accepted response:

import { Queue } from 'bullmq';
import { redisConnection } from './redis';

export const emailQueue = new Queue('email-dispatch', { connection: redisConnection });

// Inside Express or Next.js route handler:
export async function handleUserRegistration(req, res) {
  const user = await createUser(req.body);

  // Offload non-blocking notification to background worker
  await emailQueue.add('send-welcome', {
    userId: user.id,
    email: user.email,
  }, {
    attempts: 3,
    backoff: { type: 'exponential', delay: 2000 },
  });

  return res.status(201).json({ success: true, userId: user.id });
}

This guarantees your API response times remain under 20 milliseconds, regardless of whether external services are slow or down.

4. Next.js 15 Server Components & Core Web Vitals

Next.js 15 App Router allows us to fetch data directly on the server without shipping bulky client-side JavaScript libraries (like Axios or large parsing utilities) to the user's browser.

Best Practices:

Default to Server Components: Only mark components with 'use client' when they require browser event listeners (onClick, onChange) or React hooks (useState, useEffect).
Streaming with Suspense: Wrap slow third-party data widgets in <Suspense fallback={<Skeleton />}> so the primary page content renders instantly.
Image Optimization: Always use Next.js <Image /> with explicit dimensions and modern WebP / AVIF format conversions.

Summary Checklist for Production Full-Stack Applications

Architectural Component	Recommended Practice	Benefit
Database Connections	pgBouncer + max 20 client pool	Prevents connection starvation
API Endpoints	Node.js Express + Zod validation	Type-safe, sub-10ms latency
Background Work	BullMQ + Redis worker queues	Immune to third-party timeout lag
Frontend UI	Next.js 15 RSC + Tailwind CSS	Sub-second LCP, zero layout shifts
Security & Auth	Asymmetric RS256 JWT + Redis rate limits	Protection against brute force & DDoS

Partner With a Freelance Full-Stack Developer & Architect

Are you building a new custom web application, enterprise SaaS product, or scaling an existing Node.js & Next.js platform?

As a Freelance Software Developer & Solution Architect based in Kerala, India, I help founders and engineering teams build robust, production-ready web systems tailored to business goals.

Explore My Web Development Services or Schedule an Initial Project Discovery Call.

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

Abin S Chandran — Mon, 17 Aug 2026 08:07:45 +0000

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