DEV Community: Rick13211

Your Backend is Making Users Wait 7 Seconds. Here's the Fix.

Rick13211 — Sat, 11 Jul 2026 16:39:17 +0000

Most of the time, unknowingly, a developer-kun uses synchronous APIs where the server expects a response immediately and halts all other work.

This works fine when resources are plentiful and latency is low.

But flip the situation — backend is busy, latency is high. A sync API will wait indefinitely unless programmed otherwise. Bad UX. Angry users. Sad developer-kun.

The Problem — A Real Example

A user signs up on your platform. Your server needs to:

Send a welcome email — 2 seconds
Receive and process their profile picture — 3 seconds
Send a Slack notification — 1 second
Log the event to analytics — 1 second

Total: 7 seconds of the user staring at a loading spinner.

On one server, doing everything synchronously, that's what you get. And that's assuming nothing goes wrong — if the email service is slow that day, add another 5 seconds on top.

The user thinks your app is broken. They leave. You cry.

The Fix — Async Architecture with Queues

Instead of doing everything in the request-response cycle, you:

Save the user to the database
Queue up the heavy work
Return a response immediately
Workers pick up the queued jobs in the background

User signs up
     ↓
Server saves to DB (fast)
     ↓
Queues: welcome email, profile processing, slack notification, analytics
     ↓
Returns response in ~50ms ← user is happy

     Meanwhile, in the background:
     Worker picks up jobs one by one
     Emails sent ->  Slack notified ->  Analytics logged

The user gets their response in 50ms. The work still happens. Nobody waits.

Enter BullMQ

BullMQ is a Node.js job queue library backed by Redis. Think of it as a post office:

Producer — your API drops a letter (job) in the mailbox (queue)
Queue — holds the letters until a postman is free
Worker — the postman who picks up letters and delivers them

npm install bullmq ioredis

The Queue — Your Mailbox

import { Queue } from 'bullmq';
import Redis from 'ioredis';

// Connect to Redis — BullMQ uses Redis to store jobs
const connection = new Redis({
  host: process.env.REDIS_HOST || 'localhost',
  port: process.env.REDIS_PORT || 6379,
  maxRetriesPerRequest: null, // required by BullMQ
});

// Define the queue
export const emailQueue = new Queue('emails', { connection });

// Helper to add a welcome email job
export async function queueWelcomeEmail(user) {
  await emailQueue.add(
    'welcome-email',     // job name
    {                    // job data — available to the worker
      userId: user.id,
      email: user.email,
      name: user.name,
    },
    {
      attempts: 3,       // retry up to 3 times if it fails
      backoff: {
        type: 'exponential',
        delay: 2000,     // wait 2s, then 4s, then 8s between retries
      },
      removeOnComplete: 100, // keep last 100 completed jobs in Redis
      removeOnFail: 50,      // keep last 50 failed jobs for inspection
    }
  );
  console.log(`Queued welcome email for ${user.email}`);
}

// Helper to add an account deletion email job
export async function queueAccountDeleteEmail(user) {
  await emailQueue.add(
    'account-delete-email',
    {
      userId: user.id,
      email: user.email,
      name: user.name,
    },
    {
      attempts: 3,
      backoff: { type: 'exponential', delay: 2000 },
      removeOnComplete: 100,
      removeOnFail: 50,
    }
  );
  console.log(`Queued account deletion email for ${user.email}`);
}

What's happening here?

new Queue('emails', { connection }) — creates a queue called "emails" backed by Redis. If the queue doesn't exist, BullMQ creates it automatically.

emailQueue.add(name, data, options) — drops a job into the queue. Returns immediately — this is the non-blocking part. Your API doesn't wait for the email to send.

attempts: 3 — if the job fails (email service is down, network error etc), BullMQ retries automatically up to 3 times.

backoff: exponential — waits 2s before retry 1, 4s before retry 2, 8s before retry 3. Gives the failing service time to recover instead of hammering it.

The Worker — Your Postman

import { Worker } from 'bullmq';
import Redis from 'ioredis';

const connection = new Redis({
  host: process.env.REDIS_HOST || 'localhost',
  port: process.env.REDIS_PORT || 6379,
  maxRetriesPerRequest: null,
});

const worker = new Worker(
  'emails',              // which queue to watch
  async (job) => {       // function to run for each job
    console.log(`Processing job: ${job.name}`, job.data);

    if (job.name === 'welcome-email') {
      const { email, name } = job.data;
      await sendWelcomeEmail(email, name);
    } else if (job.name === 'account-delete-email') {
      const { email, name } = job.data;
      await sendAccountDeleteEmail(email, name);
    }
  },
  {
    connection,
    concurrency: 5, // process up to 5 jobs simultaneously
  }
);

// Simulate sending a welcome email
async function sendWelcomeEmail(email, name) {
  await new Promise(resolve => setTimeout(resolve, 1000)); // simulate delay
  console.log(`  Welcome email sent to ${name} at ${email}`);
}

// Simulate sending a deletion email
async function sendAccountDeleteEmail(email, name) {
  await new Promise(resolve => setTimeout(resolve, 1000));
  console.log(`  Account deletion email sent to ${name} at ${email}`);
}

// Event listeners — know what's happening
worker.on('completed', (job) => {
  console.log(` Job ${job.id} (${job.name}) completed`);
});

worker.on('failed', (job, err) => {
  console.error(` Job ${job.id} (${job.name}) failed:`, err.message);
});

worker.on('active', (job) => {
  console.log(`  Job ${job.id} (${job.name}) is now active`);
});

console.log('Email worker started, waiting for jobs...');

What's happening here?

new Worker('emails', handler, options) — watches the "emails" queue. Every time a job arrives, it calls the handler function with that job.

concurrency: 5 — process up to 5 jobs simultaneously. Without this, jobs are processed one at a time. With 100 emails queued, concurrency of 5 means they're processed in batches of 5 — 5x faster.

job.name and job.data — the name and data you passed when adding the job. The worker uses the name to decide what to do.

Wire it into your API

In your signup route — call queueWelcomeEmail after saving the user. Notice: no await. Fire and forget. The user gets their response immediately.

import { queueWelcomeEmail } from '../queues/emailQueue.js';

router.post('/signup', async (req, res) => {
  // Save user to database
  const user = await createUser(req.body);

  // Queue the email — non-blocking, returns immediately
  queueWelcomeEmail(user);

  // User gets their response in ~50ms
  res.status(201).json({ user, accessToken, refreshToken });
});

In your delete user route:

import { queueAccountDeleteEmail } from '../queues/emailQueue.js';

router.delete('/:id', authenticate, authorize('admin'), async (req, res) => {
  const result = await pool.query(
    'DELETE FROM users WHERE id = $1 RETURNING *', [id]
  );

  // Queue deletion email — non-blocking
  queueAccountDeleteEmail(result.rows[0]);

  res.json({ message: 'User deleted' });
});

Run it

# Terminal 1 — your API server
node index.js

# Terminal 2 — your email worker (separate process)
node src/queues/emailWorker.js

# Terminal 3 — trigger a signup
curl -X POST http://localhost:3000/auth/signup \
  -H "Content-Type: application/json" \
  -d '{"name":"Prometheus","email":"p@test.com","password":"secret123"}'

Terminal 1 (API):

Queued welcome email for p@test.com   ← instant

Terminal 2 (Worker):

⚙️  Job 1 (welcome-email) is now active
Processing job: welcome-email { userId: 1, email: 'p@test.com', name: 'Prometheus' }
-  Welcome email sent to Prometheus at p@test.com
- Job 1 (welcome-email) completed

API responded instantly. Email sent in the background. User is happy.

What About Failures?

This is where BullMQ really shines. Suppose SendGrid goes down mid-request:

Job fires → SendGrid returns 503 → BullMQ catches the error
Wait 2 seconds → retry 1 → SendGrid still down
Wait 4 seconds → retry 2 → SendGrid recovered
 Email sent on attempt 3

BullMQ handles all of this automatically. You just configure attempts and backoff — the retry logic is built in.

If all 3 attempts fail, the job moves to the failed queue in Redis. You can inspect it, fix the issue, and re-queue it manually. Nothing is lost.

Inspect Your Queues in Redis

redis-cli

# See all BullMQ keys
KEYS bull:*

# See completed jobs
ZRANGE bull:emails:completed 0 -1

# Inspect a specific job
HGETALL bull:emails:1

You'll see every field — job name, data, attempts made, timestamps, status. In production you'd build a dashboard on top of this (BullMQ has an official one called Bull Board).

The Takeaway

Synchronous:  User waits 7 seconds for email + slack + analytics
Async queues: User waits 50ms. Everything else happens in background.

The rule — if a task doesn't need to finish before you respond to the user, queue it.

Welcome emails, push notifications, image resizing, PDF generation, analytics events, Slack messages — all of these belong in a queue.

Your API should do one thing: save the data and respond. Everything else is someone else's job.

Still documenting my backend journey publicly — next up is Kafka event streaming, Docker, and system design at scale.

X: [your handle]

GitHub: [your link]

I Built a Load Balancer from Scratch (No Libraries, Just Vibes)

Rick13211 — Fri, 10 Jul 2026 03:05:56 +0000

Hey everyone, I welcome you to witness one more learning of mine:

The Load Balancer!!! (Balancaahhh!!! If you prefer Mikasa's voice)

But before we jump into this cool topic of the day, we gotta learn a few terminologies first.

(Get behind me, kitten, things are gonna get wild now [smirks])

First, What is a Proxy?

A proxy is something that sits between the client and the server.

Normally:

client → server

With a Proxy:

client → Proxy → server

The client thinks it's talking to the proxy. But the proxy quietly forwards it to the real server. The client never gets to know. Classic middleman behavior.

Now — What is a Reverse Proxy?

A reverse proxy is kinda similar to a proxy, but it sits in front of the servers instead of the clients. While a regular proxy hides the client, a reverse proxy hides the servers.

3... 2... 1... What is a Load Balancer?

In layman's terms, a load balancer is something that acts as a proxy and a traffic director. It helps the system choose the correct server by using different algorithms and performing regular health checks.

                    ┌→ Server 1 (port 3001)
Client → Load  ─────┼→ Server 2 (port 3002)
         Balancer   └→ Server 3 (port 3003)

In this article, I'll share my implementation of a load balancer. The code in production will vary — use this as a reference and a learning tool.

The Code

`servers.js` — The actual backend servers

These are the servers we want our client connections redirected to.

import express from 'express';

const PORTS = [3001, 3002, 3003];

PORTS.map((port) => {
  const app = express();

  app.get('/status', (req, res) => {
    res.json({ message: `Server running on port ${port}`, port });
  });

  app.get('/health', (req, res) => {
    res.json({ status: 'healthy', port });
  });

  app.listen(port, () => {
    console.log(`Server running on port ${port}`);
  });
});

I started 3 servers on ports 3001, 3002, 3003. You can choose your own ports.

Note: Running all 3 in one file means closing the program kills all servers. For a more production-like feel, create 3 separate files and run each independently.

`loadBalancer.js` — The main event

import express from 'express';
import http from 'http';

// Track our backend servers
const servers = [
  { host: 'localhost', port: 3001, isAlive: true, connections: 0 },
  { host: 'localhost', port: 3002, isAlive: true, connections: 0 },
  { host: 'localhost', port: 3003, isAlive: true, connections: 0 },
];

Our load balancer tracks each server. In production, this list might come from a service registry or config file, but the idea is the same.

The Round Robin Algorithm

let currentIndex = 0;

const roundRobin = () => {
  const aliveServers = servers.filter(server => server.isAlive);
  if (aliveServers.length === 0) throw new Error('No alive servers');

  const server = aliveServers[currentIndex % aliveServers.length];
  currentIndex++;
  return server;
};

We filter dead servers first — no point routing to a corpse. Then currentIndex % aliveServers.length handles the rotation:

3 servers alive:
request 1 → 0 % 3 = 0 → server 3001
request 2 → 1 % 3 = 1 → server 3002
request 3 → 2 % 3 = 2 → server 3003
request 4 → 3 % 3 = 0 → server 3001 ← back to start

Infinite fair rotation. Simple but effective.

Health Checks — The Doctor in the House

async function checkHealth() {
  for (const server of servers) {
    const req = http.request(
      {
        host: server.host,
        port: server.port,
        path: '/health',
        method: 'GET',
        timeout: 2000,
      },
      (res) => {
        const wasUnhealthy = !server.isAlive;
        server.isAlive = res.statusCode === 200;

        if (wasUnhealthy && server.isAlive) {
          console.log(`Server ${server.port} is back online`);
        }
      }
    );

    req.on('error', () => {
      if (server.isAlive) console.log(`Server ${server.port} is DOWN`);
      server.isAlive = false;
    });

    req.on('timeout', () => {
      req.destroy();
      server.isAlive = false;
    });

    req.end();
  }
}

// Run every 10 seconds
setInterval(checkHealth, 10000);
checkHealth(); // run immediately on startup

Every 10 seconds, the load balancer pings /health on each backend. Gets a 200? Alive. Times out or errors? Dead — removed from rotation automatically.

The beautiful part — was Unhealthy && server.isAlive` detects resurrection. When a dead server comes back online, we log it and start routing to it again. No manual intervention needed.

The Proxy — Where the Magic Happens

`js
const loadBalancer = express();

// Stats endpoint — must come BEFORE the catch-all
loadBalancer.get('/stats', (req, res) => {
res.json(servers);
});

// Catch-all — forward every request to a backend
loadBalancer.use((req, res) => {
let server;

try {
server = roundRobin();
server.connections++;
} catch (error) {
return res.status(503).json({ error: 'All servers are down' });
}

const options = {
host: server.host,
port: server.port,
method: req.method,
path: req.url,
headers: {
...req.headers,
'x-forwarded-for': req.socket.remoteAddress,
},
};

const proxyReq = http.request(options, (proxyRes) => {
res.writeHead(proxyRes.statusCode, proxyRes.headers);
proxyRes.pipe(res); // backend → client
proxyRes.on('end', () => {
server.connections--;
});
});

req.pipe(proxyReq); // client → backend

proxyReq.on('error', () => {
server.connections--;
server.isAlive = false;
console.log(Server ${server.port} is down);
if (!res.headersSent) {
res.status(502).json({ error: 'Bad gateway' });
}
});
});

loadBalancer.listen(3000, () => {
console.log('Load balancer running on port 3000');
});
`

What's Actually Happening Here?

options — the blueprint for the forwarded request. We copy everything from the original — method, URL path, all headers. Plus, we add x-forwarded-for, which tells the backend the real client IP. Without it, every request looks like it came from 127.0.0.1 (the load balancer).

http.request(options, callback) — the load balancer makes a brand new HTTP request to the chosen backend. Like a middleman calling the restaurant on your behalf.

proxyRes.pipe(res) — when the backend responds, we don't buffer it. We pipe it — think of it like a water pipe connecting two ends. Data flows from the backend directly to the client, chunk by chunk. Memory efficient. Fast.

req.pipe(proxyReq) — same idea but the other direction. If the client sent a POST request with a body (JSON data), we pipe it to the backend. Without this line, POST request bodies arrive at the backend empty.

server.connections-- — when the response is fully sent, the connection counter drops. This server is free again.

The Stats Endpoint — Your Window Into the Matrix

bash curl http://localhost:3000/stats

json [ { "host": "localhost", "port": 3001, "isAlive": true, "connections": 2 }, { "host": "localhost", "port": 3002, "isAlive": true, "connections": 1 }, { "host": "localhost", "port": 3003, "isAlive": false, "connections": 0 } ]

Real-time state of every server — alive or dead, active connections. Your load balancer's heartbeat monitor.

Test It

`bash

Terminal 1 — start all backend servers

node servers.js

Terminal 2 — start load balancer

node loadBalancer.js

Terminal 3 — fire 9 requests

for i in {1..9}; do curl http://localhost:3000/status; echo ""; done
`

You'll see requests rotating across 3001, 3002, and 3003 in perfect order.

Now kill server 3001. Wait 10 seconds. The load balancer logs Server 3001 is DOWN. Send more requests — they only go to 3002 and 3003.

Bring 3001 back. Wait 10 seconds. It's back in rotation. The system healed itself.

THAT is why load balancers exist. Not just traffic distribution — self-healing infrastructure.

Other Algorithms Worth Knowing

Least Connections — always pick the server with the fewest active connections. Better when requests have varying processing times. Just replace roundRobin() with:

js const leastConnections = () => { const aliveServers = servers.filter(s => s.isAlive); if (aliveServers.length === 0) throw new Error('No alive servers'); return aliveServers.reduce((min, s) => s.connections < min.connections ? s : min ); };

IP Hash — hash the client's IP to always route them to the same server. Useful for sticky sessions — but breaks if you store session data in memory.

Weighted Round Robin — give more powerful servers a higher weight so they receive proportionally more traffic.

Reality Check

This is a learning implementation. In production you'd use Nginx or AWS ALB — they do everything above plus SSL termination, DDoS protection, and handle millions of requests per second.

But now you know what they're doing under the hood.

And that's what matters.

Still documenting my backend journey publicly — next up is Circuit Breakers, Kafka, Docker, and system design at scale.

Follow along on X: [@theoblivied]

GitHub: [https://github.com/Rick13211]

4 Security Bugs I Found in My Own Auth System (And How I Fixed Them)

Rick13211 — Wed, 08 Jul 2026 00:30:46 +0000

So recently I took on a challenge to learn advanced backend engineering all by myself. Quite a huge task, but I had to lock in.

Naturally, the time came when I was building a secure Authentication System with JWT Tokens — using Refresh and Access Tokens for session management.

Later, when I was studying common security attacks, I realized my own code would be pretty vulnerable in production. Here are the 4 bugs I found and exactly how I fixed them.

Bug 1 — SQL Injection

I was building query strings by directly embedding user input:

// ❌ What I was doing
const user = await pool.query(
  `SELECT * FROM users WHERE id=${id}`
)

To understand the problem, you need to understand how query parameters travel from the browser to your backend.

A normal request looks like this:

GET /users?id=10

Which produces this SQL:

SELECT * FROM users WHERE id=10

Fine. But what if an attacker sends this instead?

GET /users?id=10 OR (1=1)

Your query becomes:

SELECT * FROM users WHERE id=10 OR (1=1)

Since 1=1 is always true — this returns every single user in your database. A complete data breach from one crafted URL.

It gets worse. An attacker can send:

GET /users?id=10; DROP TABLE users;--

Your entire users table — gone.

The fix — parameterized queries:

// ✅ The right way
const user = await pool.query(
  'SELECT * FROM users WHERE id = $1',
  [id]
)

The $1 placeholder tells PostgreSQL to treat the value as data, never as SQL. No matter what the user sends — it's always just a string. Injection is impossible.

Other options: input validation, ORMs like Prisma. But parameterized queries are the foundation — always use them.

Bug 2 — Email Enumeration

I was returning different error messages for wrong email vs wrong password:

// ❌ What I was doing
if (!user) {
  return res.status(401).json({ message: 'Email not found' })
}
if (!passwordMatch) {
  return res.status(401).json({ message: 'Wrong password' })
}

Looks harmless. It's not.

An attacker can write a script that fires thousands of emails at your login endpoint. If they get "Email not found" — they move on. If they get "Wrong password" — they know that email exists in your database.

Now they have a confirmed list of valid emails. They can target them with phishing, credential stuffing, or brute force attacks. You just handed them half the work.

The fix — always return the same message:

// ✅ The right way
return res.status(401).json({ message: 'Invalid credentials' })

Same message. Same HTTP status. No information leaked about whether the email exists or the password was wrong.

Bug 3 — Password Comparison with ===

I was comparing passwords like this:

// ❌ What I was doing
if (user.password === inputPassword) {
  // login success
}

This is vulnerable to timing attacks.

String comparison in most languages stops the moment it finds a mismatching character. A password that matches the first 5 characters takes microseconds longer to reject than one that matches 0 characters.

An attacker can send thousands of password guesses and measure the response times. Over enough attempts, they can determine your password character by character — just from how long the server takes to respond.

The fix — use bcrypt.compare():

// ✅ The right way
const match = await bcrypt.compare(inputPassword, user.password)

bcrypt.compare uses a constant-time comparison algorithm — it always takes the same amount of time regardless of how many characters match. No timing signal. No leak.

And while we're here — never store plain text passwords. Always hash on signup:

const hashedPassword = await bcrypt.hash(password, 10)
// store hashedPassword in the database, never password

Bug 4 — Unrevocable Refresh Tokens

I was issuing refresh tokens as pure JWTs and forgetting about them:

// ❌ What I was doing
const refreshToken = jwt.sign(
  { userId: user.id },
  process.env.REFRESH_TOKEN_SECRET,
  { expiresIn: '7d' }
)
res.json({ accessToken, refreshToken })
// that's it — no storage, no tracking

The problem — JWTs are stateless. Once issued, you cannot invalidate them before they expire.

If a user logs out, their refresh token is still cryptographically valid for 7 days. If it gets stolen — through XSS, a compromised device, a man-in-the-middle attack — the attacker has 7 days of access and you can't do anything about it.

Your logout endpoint becomes a lie. You tell the user they're logged out. They're not.

The fix — store refresh tokens in Redis:

// ✅ The right way — on login
const refreshToken = jwt.sign({ userId: user.id }, secret, { expiresIn: '7d' })

// Store in Redis with 7 day TTL
await redis.setex(
  `refresh:${user.id}:${refreshToken}`,
  7 * 24 * 60 * 60,
  user.id.toString()
)

// On every /refresh request — check Redis first
const stored = await redis.get(`refresh:${decoded.userId}:${refreshToken}`)
if (!stored) {
  return res.status(403).json({ message: 'Invalid or expired refresh token' })
}

// On logout — delete from Redis
await redis.del(`refresh:${decoded.userId}:${refreshToken}`)
// Token is now dead even if someone has a copy

Redis TTL handles expiry automatically. No cleanup jobs needed. And logout actually works.

The Takeaway

None of these bugs would show up in basic testing. SQL injection, email enumeration, timing attacks, unrevocable tokens — they only surface when someone is actively trying to break your system.

Reading the OWASP Top 10 after building your own auth system hits completely different than reading it before. You recognize every attack because you've written the vulnerable code yourself.

That's the only way to actually learn security — build it wrong first, then understand exactly why it's wrong, then fix it properly.

What I'm using in production:

Parameterized queries with pg (node-postgres)
bcrypt for password hashing (cost factor 10)
Short-lived access tokens (15 minutes) + long-lived refresh tokens (7 days)
Refresh tokens stored in Redis — revocable on logout
Identical error messages for all auth failures
helmet.js for security headers
Rate limiting on auth routes (10 attempts per 15 minutes)

I'm documenting my backend learning journey publicly. If you found this useful, follow along — next up is Redis caching, Kafka event streaming, Docker, and system design.

(GitHub: )[https://github.com/Rick13211]
(X: )[https://x.com/theoblivied]

DEV Community: Rick13211

Your Backend is Making Users Wait 7 Seconds. Here's the Fix.

The Problem — A Real Example

The Fix — Async Architecture with Queues

Enter BullMQ

The Queue — Your Mailbox

The Worker — Your Postman

Wire it into your API

Run it

What About Failures?

Inspect Your Queues in Redis

The Takeaway

I Built a Load Balancer from Scratch (No Libraries, Just Vibes)

First, What is a Proxy?

Now — What is a Reverse Proxy?

3... 2... 1... What is a Load Balancer?

The Code

servers.js — The actual backend servers

loadBalancer.js — The main event

The Round Robin Algorithm

Health Checks — The Doctor in the House

The Proxy — Where the Magic Happens

What's Actually Happening Here?

The Stats Endpoint — Your Window Into the Matrix

Test It

Terminal 1 — start all backend servers

Terminal 2 — start load balancer

Terminal 3 — fire 9 requests

Other Algorithms Worth Knowing

Reality Check

4 Security Bugs I Found in My Own Auth System (And How I Fixed Them)

Bug 1 — SQL Injection

Bug 2 — Email Enumeration

Bug 3 — Password Comparison with ===

Bug 4 — Unrevocable Refresh Tokens

The Takeaway

`servers.js` — The actual backend servers

`loadBalancer.js` — The main event