DEV Community: Gavin Hemsada

Senior Devs Don’t Just Catch Errors—They Manage Them

Gavin Hemsada — Sat, 21 Mar 2026 17:32:46 +0000

When you’re a junior developer, a try-catch block feels like a safety net. If you’re worried a piece of code might crash, you wrap it in a try-catch and move on. But as you scale to 50,000+ users, you quickly realize that swallowing errors is often more dangerous than letting the app crash.

A blind try-catch hides the root cause of failures, makes debugging a nightmare, and can leave your application in an inconsistent state (e.g., money deducted from a user’s balance, but the order never created because the error was caught and ignored).

Senior engineers don't just "handle" exceptions; they design Error Policies. Here are the 4 patterns that separate the pros from the amateurs.

Pattern 1: The Global Error Middleware (Centralized Handling)

In a massive Express.js app, you shouldn't have unique error-handling logic in every single route. If you have 100 endpoints, that’s 100 places where a developer might forget to log an error or send the wrong HTTP status code.

The Senior Approach: Use a centralized error-handling middleware. Your routes should only be responsible for catching the error and passing it to the next() function. This ensures that every error in your system is formatted, logged, and reported to your monitoring tools (like Sentry or Datadog) in exactly the same way.

Pattern 2: The Circuit Breaker Pattern

If your Node.js API relies on a third-party service (like a Stripe or a weather API) and that service goes down, your app shouldn't keep trying to hit it. If you have 5,000 users all waiting for a 30-second timeout from a dead external service, your Node.js event loop will grind to a halt.

The Senior Approach: Implement a Circuit Breaker. If the external service fails 5 times in a row, the circuit trips. For the next 30 seconds, your app doesn't even try to hit the external API; it immediately returns a cached result or a Service Temporarily Unavailable message. This prevents a "cascading failure" from taking down your entire backend.

Pattern 3: Functional Error Returns (The Result Pattern)
Sometimes, an error isn't an exception—it's an expected outcome. For example, a user entering the wrong password isn't a "system crash"; it's a valid business logic branch. Using throw for expected logic is expensive and messy.

The Senior Approach: Return a Result object. Instead of throwing an error, return an object like { success: false, error: 'INVALID_CREDENTIALS' }. This forces the calling function to explicitly handle both the success and failure cases without the overhead of a stack trace.

Pattern 4: Operational vs. Programmer Errors

This is the biggest distinction.

Programmer Errors (Bugs): A variable is undefined, or you tried to read a property of null. These should crash the process. You want the server to restart so it doesn't stay in a broken state.

Operational Errors (Run-time): The database is busy, or a file wasn't found. These should be handled gracefully.

The Senior Approach: Distinguish between the two. Use a tool like process.on('unhandledRejection') to log programmer errors and exit the process cleanly, while using structured catch blocks for operational errors.

Here is how a Senior Dev implements Centralized Handling and Custom Error Classes in Express.

// 1. Define a Custom Error Class
class AppError extends Error {
  constructor(message, statusCode) {
    super(message);
    this.statusCode = statusCode;
    this.isOperational = true; // Distinguish from programmer bugs
    Error.captureStackTrace(this, this.constructor);
  }
}

// 2. The Controller (Clean and focused)
app.get('/api/orders/:id', async (req, res, next) => {
  try {
    const order = await Order.findById(req.params.id);
    if (!order) {
      // We don't handle the response here. We pass it to the 'gatekeeper'.
      return next(new AppError('No order found with that ID', 404));
    }
    res.status(200).json(order);
  } catch (err) {
    next(err); // Pass unexpected errors to global handler
  }
});

// 3. The Global Error Middleware (The Gatekeeper)
app.use((err, req, res, next) => {
  err.statusCode = err.statusCode || 500;

  // Log to Sentry/Datadog for monitoring
  console.error(`[ERROR] ${err.message} - Stack: ${err.stack}`);

  // Send a clean, non-leaky response to the client
  res.status(err.statusCode).json({
    status: err.statusCode < 500 ? 'fail' : 'error',
    message: err.isOperational ? err.message : 'Something went very wrong!'
  });
});

Moving Beyond Disk: How Redis Supercharges Your App Performance

Gavin Hemsada — Sat, 21 Mar 2026 17:10:45 +0000

If your database is the heart of your application, Redis is the adrenaline. When we hit 50,000 users, our PostgreSQL instance began to sweat. CPU usage was spiking, and read-heavy endpoints were dragging the whole system down. We realized that the fastest database query is the one that never happens.

The RAM vs. Disk Reality

Traditional databases like PostgreSQL or MongoDB are incredible for data integrity, but they live on the disk. Even with SSDs, disk I/O is orders of magnitude slower than RAM. Redis lives entirely in memory. By moving our most expensive and most frequent queries into Redis, we moved from 200ms response times to sub-10ms.

We applied the 90/10 Rule: 90% of our traffic was hitting only 10% of our data. For us, this was user session data, global configuration settings, and the top trending lists. There is no reason to ask a SQL database to calculate the Top 10 list every time a user refreshes their home page. We calculate it once, store it in Redis, and serve it instantly.

Implementing the Cache-Aside Pattern

Scaling smoothly required a disciplined approach to how we used Redis. We adopted the Cache-Aside pattern. The logic is simple:

The app checks Redis for the data.
If it’s there (a Cache Hit), return it immediately.
If it’s not (a Cache Miss), query the DB, store the result in Redis for next time, and then return it.

The challenge here is Cache Invalidation. There is nothing worse for a user than updating their profile and seeing the old data for the next hour. We implemented a Write-Through strategy for critical data: whenever a user updated their profile, the code would simultaneously update the DB and delete the old Redis key.

Preventing the "Thundering Herd"

One lesson we learned the hard way was the Thundering Herd problem. Imagine a cache key for a trending post expires. Suddenly, 5,000 concurrent users see a Cache Miss and all 5,000 hit the database at the exact same millisecond. This can crash a database instantly.

To solve this, we used Jitter (adding a random few seconds to TTLs so they don't all expire at once) and Atomic Locking. If a key expires, only the first request is allowed to rebuild the cache, while the others wait or receive a slightly stale version. This kept our database load stable, even during massive traffic spikes. Redis wasn't just a performance booster; it became our primary shield against infrastructure failure.

This sample shows how to wrap a database query with Redis, handle Cache Misses, and implement Cache Invalidation.

const redis = require('redis');
const client = redis.createClient({ url: 'redis://localhost:6379' });
client.connect();

const GET_POST_TTL = 3600; // 1 Hour

app.get('/api/posts/:slug', async (req, res) => {
  const { slug } = req.params;
  const cacheKey = `post:${slug}`;

  try {
    // 1. Try to fetch from Redis Cache
    const cachedPost = await client.get(cacheKey);

    if (cachedPost) {
      console.log('CACHE HIT');
      return res.json(JSON.parse(cachedPost));
    }

    // 2. Cache Miss: Query the primary Database
    console.log('CACHE MISS - Querying DB');
    const post = await db.posts.findFirst({ where: { slug } });

    if (!post) return res.status(404).json({ error: 'Post not found' });

    // 3. Store in Redis with an Expiry (TTL)
    // Adding 'Jitter' (random seconds) prevents the 'Thundering Herd' problem
    const jitter = Math.floor(Math.random() * 60); 
    await client.setEx(cacheKey, GET_POST_TTL + jitter, JSON.stringify(post));

    return res.json(post);
  } catch (error) {
    console.error('Redis/DB Error:', error);
    // Fail-safe: If Redis is down, still try to serve from DB
    const post = await db.posts.findFirst({ where: { slug } });
    res.json(post);
  }
});

// 4. Cache Invalidation (Write-Through)
app.put('/api/posts/:slug', async (req, res) => {
  const { slug } = req.params;

  // Update DB
  await db.posts.update({ where: { slug }, data: req.body });

  // Invalidate Cache: Delete the old key so the next GET fetches fresh data
  await client.del(`post:${slug}`);

  res.status(200).json({ message: 'Post updated and cache cleared' });
});

Your API Is Returning Too Much Data And It’s Costing You Performance

Gavin Hemsada — Sat, 21 Mar 2026 16:37:07 +0000

In the early days of a startup, functional is the goal. You write a query, you get the data, and you send it to the frontend. But as we scaled past 50,000 users, that functional code became a massive liability. We realized that frontend performance means nothing if your backend is bloated. When every millisecond counts, your API response strategy is the difference between a smooth user experience and a hanging loading spinner.

The Invisible Cost of SELECT

The most common mistake Node.js developers make is over-fetching. We often use SELECT * or return entire Mongoose documents because it’s easier. However, at scale, this is devastating. Every extra field you send adds to the payload size, which increases network latency. More importantly, it increases the time the Node.js process spends on JSON serialization.

Converting a massive object into a JSON string is a CPU-intensive, synchronous operation. If your CPU is busy stringifying a 2MB response for User A, User B’s request is sitting in the event loop queue, waiting. We solved this by implementing strict Data Transfer Objects (DTOs). If the mobile app only needs the username and profile_pic, that is all the SQL query should fetch. This reduced our internal bus traffic and slashed response times by 30%.

Master the Event Loop

Node.js is single-threaded. This is its greatest strength and its primary weakness. To scale to 50K users, you must treat the Event Loop as a sacred resource. Any synchronous logic like heavy data transformation, complex regex on large strings, or fs.readSync will block the loop.

When the loop is blocked, the server is effectively dead to all other users. We audited our code to ensure that all heavy lifting was either moved to a background worker (like BullMQ) or handled using asynchronous patterns. We also utilized setImmediate() to break up long-running loops into smaller chunks, allowing the event loop to breathe and process incoming I/O between iterations.

Compression: Gzip vs. Brotli

Finally, never send raw text. We implemented the compression middleware in Express, but we took it a step further by favoring Brotli over Gzip for supported browsers. Brotli offers better compression ratios for text-based assets like JSON.

By compressing our responses, we reduced our bandwidth costs significantly. However, remember that compression itself costs CPU cycles. The sweet spot we found was setting a threshold (e.g., only compress responses larger than 1KB) to ensure we weren't wasting CPU power on tiny payloads where the overhead of compression outweighed the savings.

This sample demonstrates how to use Brotli/Gzip compression, DTOs (Data Transfer Objects) to prevent over-fetching, and how to keep the Event Loop clear.

const express = require('express');
const compression = require('compression');
const app = express();

// 1. Implement Compression (Prioritizing Brotli for efficiency)
app.use(compression({
  level: 6, // Balance between CPU usage and compression ratio
  threshold: 1024, // Only compress responses larger than 1KB
  filter: (req, res) => {
    if (req.headers['x-no-compression']) return false;
    return compression.filter(req, res);
  }
}));

// 2. Data Transfer Object (DTO) Logic
// Avoid 'SELECT *'. Only return what the client needs.
const formatUserResponse = (user) => ({
  id: user.id,
  username: user.username,
  avatar: user.profile_image_url,
  memberSince: user.created_at
});

app.get('/api/users/:id', async (req, res) => {
  try {
    const userId = req.params.id;

    // Simulate DB call - specifically selecting fields at the query level
    const user = await db.user.findUnique({
      where: { id: userId },
      select: { id: true, username: true, profile_image_url: true, created_at: true }
    });

    if (!user) return res.status(404).json({ error: 'User not found' });

    // 3. Non-blocking processing
    // If you have heavy logic, use setImmediate to let the Event Loop breathe
    setImmediate(() => {
      console.log(`Log: Profile accessed for user ${userId}`);
    });

    res.json(formatUserResponse(user));
  } catch (err) {
    res.status(500).send('Server Error');
  }
});