What I Built

A production-grade API gateway that:

Routes requests to multiple upstream microservices

Enforces per-client rate limiting using Redis token-bucket algorithm

Logs analytics asynchronously via BullMQ worker queues

Streams live traffic metrics to a React dashboard via Socket.io

Secures all routes with JWT authentication

GitHub:

sawastik7-bit (Sawastik Bhullar) · GitHub

sawastik7-bit has 28 repositories available. Follow their code on GitHub.

github.com

Phase Breakdown

Phase 1 — Reverse Proxy
Used http-proxy-middleware to forward requests to upstream services.
Hit a nasty bug: Express strips the mount path before passing
to the proxy, so /api/users was reaching upstream as /users
instead of /api/users. Fixed it with pathRewrite to prepend
the path back.

Phase 2 — JWT Auth Middleware
Standard but important. Every request hits the auth middleware
before reaching the proxy. Invalid token = 401, no forwarding.

Phase 3 — Redis Rate Limiting (Token Bucket)
Each client gets a bucket. Every request costs 1 token.
Tokens refill at a fixed rate. If bucket is empty = 429.
Why token bucket over fixed window? It handles burst traffic
gracefully instead of hard-cutting requests at the window boundary.

Phase 4 — Async Analytics with BullMQ
This was the most interesting part. Logging every request
synchronously would add latency to every single API call.
Instead, I push a job to a BullMQ queue and return the response
immediately. A separate worker picks up the job and writes to MongoDB.
Result: 35% latency reduction on the critical path.

Phase 5 — Socket.io Worker
The BullMQ worker doesn't just write to DB — it also emits
events via Socket.io so the dashboard updates in real time.

Phase 6 — React Dashboard
Built with Vite + Recharts. Shows live request rate,
rate-limit hits, latency percentiles. Updates sub-200ms.

Phase 7 — ES Modules Throughout
Kept the entire codebase on ESM. Painful to set up with
some packages but worth it for consistency.

What I Learned

Never do sync I/O on the request path. Ever.

Redis is not just a cache — it's a coordination primitive.

BullMQ is criminally underrated for background jobs.

pathRewrite in http-proxy-middleware will save your life.

Socket.io namespaces are the right abstraction for multi-tenant real-time features.

Repo

sawastik7-bit / distributed-api-gateway-analytics

A custom API Gateway built with Node.js featuring reverse proxy, Redis rate limiting, JWT auth, async logging with BullMQ, and a real-time analytics dashboard using React and Socket.io

Distributed API Gateway & Analytics Engine

A production-grade API Gateway built with Node.js featuring reverse proxy, Redis rate limiting, JWT authentication, async logging with BullMQ, and a real-time analytics dashboard.

Architecture

Client Request
      ↓
API Gateway (Port 3000)
  → Rate Limiter (Redis)
  → JWT Auth
  → Reverse Proxy
      ↓
Microservices
  → Service A - Users (Port 4001)
  → Service B - Products (Port 4002)
      ↓
Logger → BullMQ Queue → Worker → MongoDB
                                    ↓
                          React Dashboard (Port 5173)
                          via Socket.io (Port 4003)

Features

Reverse proxy routing to microservices
Redis rate limiting (10 requests/minute per IP)
JWT authentication at gateway level
Async request logging via BullMQ message queue
Real time analytics dashboard with live charts
Request metrics: total requests, requests per minute, average response time, error rate

Tech Stack

Backend:

Node.js, Express.js
Redis (Memurai on Windows)
BullMQ (message queue)
MongoDB with Mongoose
Socket.io
JSON Web Tokens

Frontend:

React (Vite)
Recharts
Socket.io…

View on GitHub

Would love feedback on the architecture — especially around
the queue worker design and rate limiting strategy.

DEV Community

How I Built a Distributed API Gateway with Rate Limiting, BullMQ Queues, and Real-Time Analytics — From Scratch