DEV Community: Nilesh Raut

Why JSON.stringify Removes Undefined Values

Nilesh Raut — Mon, 01 Jun 2026 18:30:00 +0000

You log an object before sending it to an API:

const user = {
  id: 1,
  name: "John",
  email: undefined
};

console.log(user);

Output:

{
  id: 1,
  name: "John",
  email: undefined
}

Everything looks fine.

Then you serialize it:

const json = JSON.stringify(user);

console.log(json);

Output:

{"id":1,"name":"John"}

The email field disappears completely.

No error.

No warning.

No indication that data was removed.

This behavior surprises many developers the first time they encounter it, especially when debugging API payloads or caching systems.

Problem

JSON.stringify() does not preserve undefined values.

Consider:

const payload = {
  username: "john",
  age: undefined,
  city: undefined
};

console.log(JSON.stringify(payload));

Output:

{"username":"john"}

The properties with undefined values are omitted entirely.

This can create unexpected behavior when:

Sending API requests
Updating database records
Caching objects
Comparing payloads
Generating audit logs

Why It Happens

The behavior comes from the JSON specification itself.

JSON supports only a limited set of data types:

String
Number
Boolean
Null
Object
Array

It does not support:

undefined
Functions
Symbols

Because undefined is not a valid JSON value, JSON.stringify() excludes it from objects.

Example:

const data = {
  name: "John",
  age: undefined
};

console.log(JSON.stringify(data));

Result:

{"name":"John"}

The property is removed because JSON has no representation for undefined.

Example

Imagine a profile update API.

Frontend payload:

const updateData = {
  firstName: "John",
  lastName: undefined
};

Serialized request:

JSON.stringify(updateData);

Produces:

{
  "firstName": "John"
}

The backend never receives lastName.

Now the server cannot distinguish between:

{
  lastName: undefined
}

and:

{}

Both become:

{}

This distinction matters in partial update operations.

Production Ready Solution

Convert Undefined to Null

If you need fields to remain present, explicitly convert them.

const payload = {
  name: "John",
  email: undefined
};

const json = JSON.stringify(payload, (key, value) =>
  value === undefined ? null : value
);

Output:

{
  "name": "John",
  "email": null
}

The field remains visible.

Create a Reusable Serializer

In larger codebases, repeating replacer functions becomes messy.

A helper works better:

function safeStringify(data) {
  return JSON.stringify(data, (key, value) =>
    value === undefined ? null : value
  );
}

Usage:

const result = safeStringify(payload);

This keeps behavior consistent across services.

Define Clear API Semantics

In production APIs, it's important to define what each value means.

For example:

{
  "email": null
}

might mean:

Remove email

while

{}

might mean:

Leave email unchanged

Without clear rules, clients and servers often interpret missing fields differently.

Validate Before Serialization

Sometimes the best solution is removing invalid data intentionally.

Example:

function removeUndefined(obj) {
  return Object.fromEntries(
    Object.entries(obj).filter(
      ([_, value]) => value !== undefined
    )
  );
}

Usage:

const cleaned = removeUndefined(data);

Now the omission is explicit instead of happening silently.

Common Mistakes

Assuming Undefined Becomes Null

Many developers expect:

{
  email: undefined
}

to become:

{
  "email": null
}

That never happens automatically.

The property is removed entirely.

Debugging the Wrong Object

This is common:

console.log(payload);

shows:

{
  email: undefined
}

Then:

JSON.stringify(payload);

removes the field.

Developers often inspect the original object and assume the serialized payload contains the same data.

Always inspect the final JSON string.

Losing Fields During PATCH Requests

Suppose a frontend sends:

{
  phone: undefined
}

After serialization:

{}

The backend may interpret this as:

No changes requested

instead of:

Remove phone number

This can lead to subtle update bugs.

Forgetting Nested Objects

The behavior applies recursively.

Example:

const user = {
  profile: {
    bio: undefined
  }
};

console.log(JSON.stringify(user));

Output:

{
  "profile": {}
}

Nested properties disappear as well.

Debugging Tips

When data seems to vanish during API calls, check the serialized payload first.

Log the Actual JSON

Instead of:

console.log(payload);

use:

console.log(JSON.stringify(payload));

This reveals exactly what will be transmitted.

Compare Before and After

console.log("Original:", payload);

console.log(
  "Serialized:",
  JSON.stringify(payload)
);

The difference is often immediately obvious.

Inspect Network Requests

In browser developer tools:

Open Network tab
Select request
Check Request Payload

Many developers spend hours debugging backend code when the field was already removed by JSON.stringify() on the client.

Watch for ORM Updates

Some ORMs treat:

null

and

undefined

very differently.

Examples include:

MongoDB drivers
Prisma
Sequelize
TypeORM

Verify how your persistence layer handles missing properties versus explicit null values.

Performance Considerations

The default JSON.stringify() implementation is highly optimized.

Using a replacer function:

JSON.stringify(data, replacer)

introduces additional processing because every property is inspected.

For normal API payloads, the overhead is negligible.

For very large objects:

Cache transformed objects when possible
Avoid unnecessary serialization cycles
Benchmark large datasets before introducing custom replacers everywhere

In most production systems, correctness matters far more than the tiny performance cost.

Final Thoughts

JSON.stringify() is not removing undefined values by accident.

It's following the JSON specification.

The key thing to remember is:

{
  email: undefined
}

becomes:

{}

not:

{
  "email": null
}

Whenever a field must remain visible after serialization, convert undefined to a valid JSON value such as null.

Understanding this behavior can save a surprising amount of debugging time, especially when working with APIs, databases, caching layers, and distributed systems where missing fields and null values often have very different meanings.

For more JavaScript and Node.js debugging articles based on real production issues, I occasionally publish deep dives on NileshBlog and TechNilesh when a bug is interesting enough to document.

Error: Cannot Set Headers After They Are Sent to the Client

Nilesh Raut — Sun, 31 May 2026 18:30:00 +0000

Error: Cannot Set Headers After They Are Sent to the Client

If you've built APIs with Express for any length of time, you've probably seen this error:

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client

Or:

Cannot set headers after they are sent to the client

The frustrating part is that the application often works for some requests and fails only under specific conditions.

This error is almost always caused by sending multiple responses for the same request.

Let's break down why it happens and how to prevent it in production code.

Problem

Consider this Express route:

app.get("/users/:id", (req, res) => {
  if (!req.params.id) {
    res.status(400).json({
      error: "User ID required"
    });
  }

  res.json({
    id: req.params.id
  });
});

Looks harmless.

But if the first response is sent, Express continues executing the remaining code.

Result:

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client

The server attempts to send two responses for a single request.

HTTP doesn't allow that.

Why It Happens

A request can only receive one response.

Once Express sends:

res.send();

res.json();

res.redirect();

res.end();

the HTTP headers are already transmitted.

Any attempt to modify headers or send another response will trigger the error.

In production systems, this usually happens because of:

Missing return statements
Multiple async operations
Duplicate error handling
Middleware issues
Promise and callback mixing
Race conditions

Example

Missing Return Statement

This is the most common cause.

app.get("/profile", (req, res) => {
  if (!req.user) {
    res.status(401).json({
      error: "Unauthorized"
    });
  }

  res.json(req.user);
});

If req.user is missing:

res.status(401).json(...)

runs first.

Then:

res.json(req.user)

runs immediately afterward.

Two responses.

One request.

Crash.

Correct Version

app.get("/profile", (req, res) => {
  if (!req.user) {
    return res.status(401).json({
      error: "Unauthorized"
    });
  }

  return res.json(req.user);
});

The return statement stops execution.

Production Ready Solution

Always Return After Sending a Response

Bad:

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

Good:

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

This simple habit prevents countless bugs.

Centralize Error Handling

Instead of sending responses everywhere:

try {
  // logic
} catch (error) {
  res.status(500).json({
    error: error.message
  });
}

Use a centralized error middleware:

app.use((err, req, res, next) => {
  res.status(500).json({
    message: "Internal Server Error"
  });
});

Then:

next(error);

This reduces duplicate response logic.

Use Async/Await Properly

Problem:

app.get("/users/:id", async (req, res) => {
  const user = await User.findById(req.params.id);

  if (!user) {
    res.status(404).json({
      error: "Not found"
    });
  }

  res.json(user);
});

Fix:

app.get("/users/:id", async (req, res) => {
  const user = await User.findById(req.params.id);

  if (!user) {
    return res.status(404).json({
      error: "Not found"
    });
  }

  return res.json(user);
});

Check Before Responding

Sometimes third-party libraries may already send a response.

Express exposes:

res.headersSent

Example:

if (!res.headersSent) {
  res.status(500).json({
    error: "Unexpected error"
  });
}

Useful as a safeguard, but not a substitute for fixing the root cause.

Common Mistakes

Sending a Response Inside a Loop

Bad:

users.forEach((user) => {
  if (!user.active) {
    res.status(400).json({
      error: "Inactive user"
    });
  }
});

The loop may attempt multiple responses.

Use validation before responding.

Mixing Callbacks and Async/Await

A production bug I encountered involved code like:

app.get("/data", async (req, res) => {
  database.query(sql, (err, result) => {
    if (err) {
      res.status(500).json(err);
    }
  });

  res.json({
    success: true
  });
});

The callback may execute after the success response.

Now two responses are possible.

Choose one style:

Async/await
Promises
Callbacks

Avoid mixing them.

Calling Next() After Responding

Bad:

res.json({
  success: true
});

next();

The next middleware may attempt another response.

Instead:

return res.json({
  success: true
});

Duplicate Catch Blocks

Another common issue:

try {
  // code
} catch (err) {
  res.status(500).json(err);
  throw err;
}

The thrown error may reach another handler that also sends a response.

Now the request gets processed twice.

Debugging Tips

When this error appears in logs, don't start searching the entire codebase.

Follow a systematic approach.

Log Every Response

Temporarily add:

app.use((req, res, next) => {
  const originalJson = res.json;

  res.json = function (body) {
    console.log("Response Sent:", req.originalUrl);

    return originalJson.call(this, body);
  };

  next();
});

This quickly reveals duplicate response paths.

Check Stack Traces Carefully

Most developers only read:

Cannot set headers after they are sent

The useful information is usually lower in the stack trace.

Look for:

at ServerResponse.setHeader

Then identify the second response location.

Search for Response Methods

Search the route for:

res.send(
res.json(
res.redirect(
res.end(

If more than one execution path reaches these methods, you've found the problem.

Add Headers-Sent Logging

console.log(res.headersSent);

before sending responses.

If it prints:

true

another part of the application already responded.

Performance Considerations

Beyond crashes, duplicate response logic wastes resources.

Examples include:

Unnecessary database queries
Extra Redis lookups
Duplicate API calls
Additional CPU work
Increased response latency

A properly structured request handler should exit immediately after sending a response.

This keeps request processing predictable and efficient.

Final Thoughts

The "Cannot Set Headers After They Are Sent to the Client" error has a simple root cause:

A request received more than one response.

The fix is usually one of these:

Add missing return statements
Avoid multiple response paths
Use centralized error handling
Don't mix callbacks and async/await
Stop middleware execution after responding

Whenever I review Express code, one of the first things I check is whether every response path exits cleanly. That single habit prevents a large percentage of production API bugs before they ever reach users.

For deeper Node.js debugging patterns and backend engineering articles, I occasionally publish practical production notes on NileshBlog, Prompts and Technileshwhen a real-world issue is worth documenting.

How to Fix EADDRINUSE: Port Already in Use

Nilesh Raut — Sun, 31 May 2026 11:17:26 +0000

If you've worked with Node.js long enough, you've probably seen this error:

Error: listen EADDRINUSE: address already in use :::3000

Or:

Error: listen EADDRINUSE: address already in use 0.0.0.0:5000

Your application refuses to start because the port you're trying to bind is already occupied.

This is one of the most common issues developers encounter during local development and deployments.

Let's fix it properly.

Problem

You start your Node.js server:

node server.js

Instead of launching successfully, Node crashes:

Error: listen EADDRINUSE: address already in use :::3000

At this point, only one process can listen on a specific port.

If another process already owns that port, Node throws the EADDRINUSE error and exits.

Why It Happens

In production and development environments, this usually happens for one of these reasons:

1. Another Node.js process is already running

You accidentally started the application twice.

Example:

node server.js

Then in another terminal:

npm run dev

Both attempt to bind to port 3000.

2. A crashed process didn't release the port

This happens surprisingly often during development.

You close the terminal but the process remains alive in the background.

The port stays occupied.

3. Another application is using the port

Common examples:

Docker containers
PostgreSQL
Redis
Nginx
Another microservice
Local development tools

4. Multiple containers mapped to the same host port

Docker example:

ports:
  - "3000:3000"

Two containers trying to expose port 3000 on the host will conflict.

Example

Consider a simple Express application:

const express = require("express");

const app = express();

app.listen(3000, () => {
  console.log("Server running");
});

Start it:

node app.js

Now start it again in another terminal:

node app.js

Result:

Error: listen EADDRINUSE: address already in use :::3000

The first process already owns the port.

Production Ready Solution

Step 1: Identify Which Process Owns the Port

Linux / macOS

Find the process:

lsof -i :3000

Example output:

COMMAND   PID USER
node     8234 dev

Alternative

sudo netstat -tulpn | grep 3000

Windows

netstat -ano | findstr :3000

Output:

TCP    0.0.0.0:3000    LISTENING    12345

Locate the process:

tasklist | findstr 12345

Step 2: Kill the Process

Linux / macOS

kill -9 8234

Windows

taskkill /PID 12345 /F

The port becomes available immediately.

Step 3: Handle the Error Gracefully

Production applications should not crash without useful logs.

Example:

const PORT = process.env.PORT || 3000;

const server = app.listen(PORT, () => {
  console.log(`Running on ${PORT}`);
});

server.on("error", (err) => {
  if (err.code === "EADDRINUSE") {
    console.error(`Port ${PORT} already in use`);
    process.exit(1);
  }

  throw err;
});

This makes troubleshooting much easier.

Step 4: Use Environment Variables

Hardcoding ports causes unnecessary conflicts.

Bad:

app.listen(3000);

Better:

const PORT = process.env.PORT || 3000;

app.listen(PORT);

Run:

PORT=5000 node app.js

This becomes especially useful when running multiple services locally.

Step 5: Auto-Detect an Available Port

For internal tools and development environments:

const getPort = require("get-port");

(async () => {
  const port = await getPort({
    port: 3000
  });

  app.listen(port);
})();

The application automatically chooses an available port.

Common Mistakes

Killing the Wrong Process

Many developers immediately run:

kill -9 <pid>

Without verifying what owns the port.

Always inspect first.

I've seen developers accidentally terminate databases, Redis instances, and even production services on shared servers.

Assuming the Port Is Free

Just because a terminal was closed doesn't mean the process stopped.

Always verify:

lsof -i :3000

before making assumptions.

Hardcoding Ports Everywhere

Large projects often contain:

scattered throughout the codebase.

Use environment variables instead.

Ignoring Docker Port Mapping

A common issue:

service-a:
  ports:
    - "3000:3000"

service-b:
  ports:
    - "3000:3000"

Docker won't allow both containers to bind the same host port.

Assign unique host ports.

Debugging Tips

When EADDRINUSE appears repeatedly, I usually follow this checklist.

Verify the owning process

lsof -i :3000

Check background Node processes

ps aux | grep node

You'll often find forgotten development servers.

Check Docker containers

docker ps

Look for containers exposing the conflicting port.

Check PM2

If you're using PM2:

pm2 list

A previously deployed process may still be running.

Check startup scripts

Sometimes systemd, PM2, Docker Compose, or Kubernetes automatically restart processes after they're killed.

The port immediately becomes occupied again.

Verify what's managing the service.

Performance Considerations

Repeatedly spawning and killing processes during development can leave orphaned processes consuming memory and CPU.

A few recommendations:

Use process managers responsibly
Avoid multiple watchers running simultaneously
Shut down servers gracefully
Monitor active processes regularly

For Express applications, graceful shutdown looks like this:

process.on("SIGTERM", () => {
  server.close(() => {
    console.log("Server closed");
    process.exit(0);
  });
});

This helps release ports cleanly.

Final Thoughts

EADDRINUSE isn't really a Node.js problem.

It's an operating system telling you that another process already owns the network port.

The fastest way to solve it is:

Identify the process
Verify it's safe to stop
Kill it if necessary
Use configurable ports
Add proper error handling

Those five steps eliminate most port-related startup issues in both local development and production environments.

If you're building backend systems regularly, keeping a small troubleshooting reference for common Node.js errors can save hours over time. I maintain similar engineering notes across projects and occasionally publish deeper backend debugging guides on NileshBlog.Tech and TechNilesh when a production issue is worth documenting.

Hot To Run LLMs Locally

Nilesh Raut — Thu, 21 May 2026 15:34:05 +0000

If you are using Claude API, OpenAI API, Cursor, or AI coding tools daily, your API bill can grow very fast.

A lot of developers are now moving to local LLM setups because they want:

Lower AI costs
Offline AI access
Better privacy
Faster experimentation
No API limits

The good news is:

You can now run powerful AI models directly on your laptop using tools like Ollama (run llm locally).

This setup works great for:

Coding help
Refactoring
Learning
Documentation
AI chat
Small local agents

Let’s set it up step by step.

Step 1: Install Ollama

Download Ollama

Install it normally like any software.

After installation, open CMD or Terminal and check:

ollama --version

If you see a version number, it is installed correctly.

Step 2: Download Your First AI Model

Now pull a model locally.

Example:

ollama pull llama3

Or for coding:

ollama pull qwen2.5-coder:7b

The first download may take a few minutes because models are several GB in size.

Step 3: Run the Model

Start chatting with the model:

ollama run llama3

Example:

>>> Explain Docker in simple words

You now have a local AI assistant running directly on your machine.

No API required.

Step 4: Use It Inside VS Code

Install:

Continue.dev
Cline

Both work with Ollama locally.

In Continue.dev config:

{
  "models": [
    {
      "title": "Local AI",
      "provider": "ollama",
      "model": "qwen2.5-coder:7b"
    }
  ]
}

Now VS Code can use your local model for:

Code generation
Refactoring
Debugging
Chat

Step 5: Open Chat UI in Browser

You can also use a ChatGPT-like interface locally.

Install Open WebUI using Docker:

docker run -d \
-p 3000:8080 \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
--name open-webui \
ghcr.io/open-webui/open-webui:main

Open:

http://localhost:3000

Now you have your own private AI chat app.

Recommended Models

Model	Best For
Qwen2.5 Coder	Coding
DeepSeek Coder	Refactoring
Llama 3	General AI
Phi	Low-end laptops
Mistral	Fast responses

Minimum Hardware

Basic setup:

16GB RAM recommended
SSD storage
NVIDIA GPU helps a lot

CPU-only works too, but slower.

Why Developers Like Local AI

Main reasons:

No monthly API bills
More privacy
Works offline
Full control
Easy experimentation

For daily coding workflows, local LLMs are becoming surprisingly useful.

Cloud models are still stronger for advanced reasoning, but local AI is now good enough for many real-world tasks.

Final Thoughts

If you are spending too much on AI APIs, this is probably the easiest way to reduce costs.

Start simple:

Install Ollama
Pull one coding model
Connect it to VS Code

That alone can replace a large percentage of your daily AI usage.

Useful links:

From PR to Production: How Kubernetes Deployments Actually Work (Microservices in the Real World)

Nilesh Raut — Sun, 22 Feb 2026 16:23:51 +0000

Most developers know how to write code.

Fewer understand what actually happens after clicking “Merge Pull Request.”

And almost nobody truly understands what Kubernetes is doing during a production deployment — until something breaks.

This post is a practical walkthrough of how code moves from PR → CI/CD → Helm → Kubernetes → Production, especially in a microservices setup.

If you’ve ever shipped something that worked locally but behaved differently in production, this is for you.

First: Kubernetes Doesn’t “Deploy” Your Code

This mental model changes everything.

Kubernetes doesn’t deploy applications the way we think about deployments.

It maintains desired state.

You declare:

“I want 3 replicas.”
“I want image order-service:1.4.2.”
“I want these resource limits.”

Kubernetes continuously checks:

Does current state match desired state?

If not, it fixes it.

That’s the entire system.

Everything else — rolling updates, restarts, scaling — is just reconciliation.

What Happens After You Merge a PR

Let’s break this down in a real production workflow.

Step 1 — PR is merged

You merge code into main or develop.

No one logs into the cluster.

No one runs kubectl.

Step 2 — CI/CD pipeline runs

The pipeline:

Runs tests (fail fast)
Builds a Docker image
Tags it (usually with commit SHA)
Pushes it to a container registry

Example image tag:

order-service:1.4.2-a8f3d21

One-line rule: Never use latest in production.

You want immutable, traceable builds.

Step 3 — Deployment is triggered

Two common approaches:

Option A – CI runs Helm directly

helm upgrade order-service --set image.tag=1.4.2-a8f3d21

This updates the Kubernetes Deployment spec.

Option B – GitOps (ArgoCD / Flux)
CI updates a config repo → GitOps controller detects change → syncs cluster.

Either way, Kubernetes receives an updated Deployment object.

What Kubernetes Actually Does Next

This is where things get interesting.

If the image tag changed inside:

.spec.template

Kubernetes:

Creates a new ReplicaSet
Starts new pods with the new image
Waits for readiness probe to succeed
Gradually terminates old pods

This is a rolling update.

No downtime if configured correctly.

No Helm magic.

Just the Deployment controller doing its job.

Important: What Actually Triggers a Rollout

Only changes inside .spec.template trigger new ReplicaSets.

Examples that trigger rollout:

Image change
Environment variable change
Resource limit change
Container command change

Examples that do NOT:

Changing replica count (only scales)
Updating a Service
Editing comments

Understanding this prevents confusion in production.

Small System vs Microservices: What Changes?

Small System (Single Service)

One Deployment
One Service
One Helm chart
One pipeline

Simple mental model.
Easier debugging.
Larger blast radius.

Microservices (Real World)

auth-service
order-service
payment-service
gateway

Each:

Has its own Deployment
Has its own Helm release
Scales independently
Deploys independently

When order-service updates, only that Deployment rolls.

Other services remain untouched.

This isolation is the real advantage of microservices.

But it comes with operational complexity.

Real Production Mistakes I’ve Seen

1. Memory limit reduced “just a little”

Pods started OOM-killing under load during rollout.
Traffic dropped.
Rollback saved the night.

Lesson: Resource changes are real deployments.

2. ConfigMap updated but pods didn’t restart

ConfigMap changes do not restart pods automatically.
You must trigger rollout manually or use checksum annotations.

Lesson: Not everything behaves how you expect.

3. Using `latest` tag

Rollback becomes unpredictable.
You lose traceability.

Lesson: Immutable image tags are non-negotiable.

Security Awareness in Deployment

Things that matter more than people admit:

No cluster-admin access for developers
Proper RBAC
Secrets stored securely (not in plain values.yaml)
Resource limits on every container
Liveness and readiness probes configured

A deployment is also a security event.

Treat it that way.

The Real Engineering Mindset

Don’t think:

“How do I deploy?”

Think:

“What changed in .spec.template?”

If you understand that, you understand Kubernetes deployments.

Helm just renders YAML.

CI just builds images.

Kubernetes enforces desired state.

That’s the real system.

Final Thought

Kubernetes deployments feel complex until you understand the reconciliation loop.

Once you do, they become predictable.

And predictability is what keeps production stable.

If you want a deeper breakdown with diagrams, failure scenarios, and production war stories, I’ve written the full long-form version here:

👉 https://nileshblog.tech/from-code-to-kubernetes-production-deployment-guide/

Why Your Node.js App Is Fast Locally but Slow in Production

Nilesh Raut — Wed, 18 Feb 2026 21:18:00 +0000

If you’ve built a Node.js app, you’ve probably experienced this exact moment:

“It’s blazing fast on my laptop… why is it crawling in production?”

This isn’t bad luck. It’s a pattern. I’ve seen it across startups, scale-ups, and even mature systems. The gap between local performance and production performance exists because production is a completely different environment — more users, more network hops, more failure modes, and far fewer shortcuts.

Let’s break down the real reasons this happens and what actually fixes it.

1. Your Local Machine Is Lying to You

Locally, everything is optimized in your favor:

Requests come from localhost
Database runs on the same machine
No real network latency
Almost zero concurrency
Warm caches
No security layers slowing things down

Production doesn’t have that luxury.

In production:

Every request crosses networks
Databases are remote
TLS is enabled
Load balancers exist
Multiple users hit the same resources at once

Your app isn’t slower. Reality is heavier.

2. Database Latency Is the Silent Killer

Locally, a database query might take 2–5 ms.
In production, that same query can take 50–200 ms.

Why?

Network round trips
Cold caches
Larger datasets
Missing indexes
Shared database load

A classic example:

await User.find({ email });

This feels instant locally with 100 rows.
In production with millions of records and no index? It’s a time bomb.

Fix:

Add proper indexes
Log slow queries
Never assume “simple queries” are cheap

3. Connection Pooling Misconfigurations

One of the most common Node.js production issues.

Locally, you might run:

1 Node process
1 database connection

In production:

Multiple Node processes
Each opens its own DB connections
Database connection limit gets exhausted

Symptoms:

Random slowness
Timeouts
Requests hanging without errors

Fix:

Configure connection pools explicitly
Align pool size with DB limits
Monitor active connections

If you don’t control this, your app collapses under load.

4. Blocking the Event Loop (Without Realizing It)

Node.js is fast — until you block it.

Common production-only blockers:

Heavy JSON parsing
Synchronous file operations
CPU-heavy loops
Poorly written logging

This code looks harmless:

JSON.parse(largePayload);

Under real traffic, it can freeze your server.

Locally, you never notice it.
In production, concurrency exposes it instantly.

Fix:

Avoid sync operations
Offload CPU work to workers
Measure event loop lag

5. Missing Timeouts Everywhere

Local environments forgive mistakes. Production doesn’t.

Without timeouts:

External APIs hang
Database calls stall
Requests pile up
Node keeps waiting forever

Eventually, everything slows down.

Fix:
Always define timeouts:

HTTP clients
Database queries
Internal service calls

Timeouts are not pessimism — they are survival.

6. Logging Becomes a Performance Problem

In development, logging is cheap.
In production, logging can destroy performance.

Reasons:

Synchronous log writes
Console logging under high load
Log aggregation delays

This line can be surprisingly expensive:

console.log(req.body);

Multiply it by thousands of requests per second.

Fix:

Use async loggers
Reduce log volume
Never log large payloads by default

7. Scaling Without Understanding Throughput

Adding more servers doesn’t always help.

If your bottleneck is:

A single database
A shared cache
A rate-limited API

Horizontal scaling just amplifies the problem.

This is why apps feel slower after scaling.

Fix:

Identify the real bottleneck
Scale databases and caches intentionally
Add backpressure and rate limits

8. You’re Not Testing Production-Like Load

Most teams test functionality, not behavior under stress.

Local testing usually means:

One request at a time
Clean startup state
Happy paths only

Production means:

Traffic spikes
Slow dependencies
Partial failures

Fix:

Load test before release
Test with realistic data sizes
Simulate failures, not just success

Final Thoughts

Your Node.js app isn’t “slow in production.”
It’s honest in production.

Local environments hide latency, concurrency, and failure. Production exposes them all at once.

If you want consistent performance:

Respect the network
Measure everything
Design for concurrency
Expect things to fail

Fast local performance is a confidence boost.
Fast production performance is an engineering achievement.

Idempotency: The Concept Everyone Mentions but Few Implement Correctly

Nilesh Raut — Mon, 16 Feb 2026 20:06:00 +0000

Idempotency is one of those words that shows up everywhere: system design interviews, API docs, architecture diagrams, and postmortems. Everyone nods when it’s mentioned. Few teams actually implement it correctly.

I’ve seen idempotency “implemented” with comments, flags, retries, or blind faith in the network. And I’ve also seen real production outages that could have been avoided with a proper idempotency strategy.

This article is about what idempotency really means in practice, where it breaks down, and how to implement it in real systems—not slides.

What Idempotency Actually Means (Beyond the Definition)

The textbook definition:

An operation is idempotent if performing it multiple times has the same effect as performing it once.

That’s technically correct but operationally incomplete.

In real systems, idempotency is about protecting your system from duplicates caused by retries, timeouts, race conditions, and partial failures.

If your API client retries because:

the network dropped,
the load balancer timed out,
the user double-clicked,
a worker crashed mid-request,

your system should not:

charge twice,
create duplicate records,
send duplicate emails,
corrupt state.

That’s the real problem idempotency solves.

Where Idempotency Matters (and Where It Doesn’t)

Common places it does matter

Payments and billing
Order creation
Inventory reservations
Webhooks
Background jobs and queues
External API integrations

Places it usually doesn’t

Pure reads (GET)
Analytics counters (if approximate is acceptable)
Fire-and-forget logging

If an operation changes money, state, or inventory, idempotency is not optional.

The Biggest Misconception: “POST Is Not Idempotent”

You’ll often hear:

GET is idempotent, POST is not.

That’s an HTTP convention, not a system guarantee.

You can (and often must) make POST requests idempotent at the application level. Payments APIs do this all the time.

The HTTP method does not save you. Your backend design does.

The Naive (and Wrong) Implementations

1. “We Just Retry”

Retries without idempotency multiply bugs.

If your payment service retries blindly and your backend creates a new record each time, you’ve just automated duplication.

Retries are only safe after idempotency is enforced.

2. “We Check If It Exists”

Example:

SELECT * FROM orders WHERE user_id = ?
IF NOT EXISTS → INSERT

This fails under concurrency.

Two requests arrive at the same time:

both see “not exists”
both insert
congratulations, you have duplicates

This is a race condition, not idempotency.

3. “We Use a Boolean Flag”

Flags like is_processed = true work only if:

the operation is atomic
the write is guaranteed to happen once
there’s no partial failure

In distributed systems, those assumptions rarely hold.

The Correct Mental Model

Idempotency is about deduplicating intent, not requests.

You don’t care how many times a request arrives.
You care that the same logical action is processed once.

That’s why idempotency keys exist.

Idempotency Keys: The Foundation

An idempotency key is a client-generated unique identifier for a logical operation.

Example:

Idempotency-Key: 7f3c9c2e-...

Rules:

Same logical action → same key
Different action → different key
Client must retry with the same key

A Minimal, Correct Implementation

Step 1: Store the key

Create a table or cache entry:

idempotency_key
request_hash
response
status
created_at

Step 2: Enforce uniqueness

The key must be unique at the database or cache level.
This prevents race conditions.

Step 3: On request

Check if the key exists
If yes:

return the stored response
1. If no:
process the request
store the response
return it

This ensures:

retries are safe
duplicates are impossible
responses are consistent

Handling Partial Failures (The Hard Part)

What if:

the operation succeeds,
but the response fails to return?

Without idempotency, the client retries and triggers a duplicate.

With idempotency:

the retry hits the same key
you return the stored success response
the system remains consistent

This is where most “implementations” fail—they don’t store the response.

Real-World Example: Payments

Payment providers treat idempotency as mandatory.

Why?

Networks are unreliable
Clients retry aggressively
Money cannot be duplicated

A payment API without idempotency is reckless.

The same logic applies to:

order creation
inventory deduction
subscription changes

Performance and Storage Trade-offs

Idempotency isn’t free.

Costs:

extra storage
lookup overhead
TTL management

Optimizations:

Use Redis with TTL for short-lived operations
Use DB for long-lived financial records
Expire keys safely (not too early)

Never trade correctness for micro-optimizations here.

Security Considerations

Treat idempotency keys as untrusted input
Scope keys per user or client
Avoid global collisions
Don’t allow attackers to replay sensitive actions indefinitely

Idempotency improves safety, but careless design can introduce replay risks.

Final Thoughts

Idempotency is not a buzzword. It’s a discipline.

If your system:

retries requests,
talks over a network,
processes money or state,

then idempotency is part of your correctness model, not an “extra feature.”

Most bugs blamed on “network issues” are actually idempotency failures.

Implement it once. Implement it right. Your future self—and your on-call rotation—will thank you.

Redis Is Not a Database (Until You Treat It Like One)

Nilesh Raut — Fri, 13 Feb 2026 19:09:28 +0000

Redis is one of those tools almost every backend engineer has used—and many have misused.

It starts simple: “Let’s just cache it.”
Then Redis works so well that it slowly becomes the system.
Before you know it, business logic depends on Redis keys, not your primary database.

That’s where things usually go wrong.

Redis is not a database by default.
But with the right discipline, configuration, and mindset—it can behave like one.

This article is about drawing that line clearly, from real production experience.

Why Redis Is Not a Database (By Default)

Redis was designed for speed first, durability second.

Out of the box, Redis optimizes for:

In-memory access
Low latency
Simple data structures
Fast eviction and expiration

What it does not guarantee by default:

Strong durability
Crash-safe persistence
Complex querying
Schema enforcement
Long-term data retention

If you treat Redis like PostgreSQL without adjusting anything, you’re setting yourself up for silent data loss.

The Common Trap: “It’s Just Temporary”

Most Redis usage begins as:

Session storage
Cache layer
Rate limiting
Feature flags
Counters

All fine use cases.

The problem appears when:

Redis becomes the only source of truth
Writes happen only to Redis
The database becomes “optional”
TTLs are misunderstood or ignored

At that point, Redis is no longer a cache.
It’s an undeclared database—and an unsafe one.

Persistence: The First Reality Check

Redis persistence is opt-in and configurable, not guaranteed.

RDB (Snapshots)

Periodic point-in-time dumps
Fast restarts
Risk of losing recent writes

One-line explanation: Good for caches, dangerous for critical writes.

AOF (Append-Only File)

Logs every write operation
Better durability
Slower writes and larger disk usage

One-line explanation: Closer to database behavior, but still not perfect.

AOF + RDB

Common production setup
Balances performance and recovery time

One-line explanation: Still requires testing, monitoring, and discipline.

If you haven’t tested:

Power loss
Container restarts
Disk-full scenarios

You don’t know how durable your Redis really is.

Redis Without Backups Is a Risk, Not a System

In real systems, I’ve seen:

Entire user sessions wiped during deploys
Order states lost after node crashes
Feature flags reset during failover

All because Redis persistence was assumed, not verified.

If Redis contains anything you cannot afford to lose:

Enable persistence explicitly
Back it up externally
Monitor persistence failures
Test restores regularly

Databases are boring because they survive disasters.
Redis is fast because it assumes you know what you’re doing.

Concurrency: Redis Is Atomic, Not Magical

Redis commands are atomic—but your system logic may not be.

Problems appear when:

Multiple keys must change together
Business rules span multiple operations
Failures happen mid-flow

Solutions Redis gives you:

Transactions (MULTI/EXEC)
Lua scripts
Single-threaded execution model

One-line explanation: You must design atomicity explicitly, not assume it.

If you’re modeling workflows, reservations, or financial state—Lua scripting is not optional.

When Redis Can Act Like a Database

Redis starts behaving like a database only when you:

Enable and test persistence
Design for crash recovery
Use Lua for invariants
Avoid TTLs for critical data
Replicate and monitor aggressively
Treat memory limits seriously

At this point, Redis stops being “just a cache” and becomes:

A fast primary store
A coordination layer
A real-time state engine

But note the cost: engineering effort.

Small Systems vs Large Systems

Small Systems

Redis as cache only
Database as source of truth
Occasional Redis loss is acceptable

This is the safest setup.

Large Systems

Redis used for locks, counters, queues, reservations
Database writes are async
Redis outages cause business impact

Here, Redis must be engineered like a database—or removed from the critical path.

There is no middle ground.

Common issues:

Unauthenticated Redis exposed internally
Accidental FLUSHALL
Memory exhaustion causing eviction
Replica lag causing stale reads

Mental Model That Actually Works

Use this rule:

If Redis data disappears, can my system recover automatically?

Yes → Redis is a cache.
No → Redis is a database, whether you admit it or not.

Once Redis becomes unrecoverable state, you must:

Engineer it like a database
Or redesign the system

Final Thoughts

Redis is an incredible tool—but it’s honest about what it is.

It will not stop you from:

Losing data
Overloading memory
Designing unsafe flows

That responsibility is yours.

Treat Redis lightly, and it will betray you quietly.
Treat it like a database, and it will reward you with speed most systems can only dream of.

The danger isn’t Redis.
The danger is pretending it’s something it never promised to be.

20+ Git Commands Every Software Engineer Should Actually Know

Nilesh Raut — Sat, 31 Jan 2026 04:07:31 +0000

Most engineers use Git every day—but only a handful of commands.
That’s fine… until something goes wrong.

A bad merge.
A wrong commit.
A force-push panic.

This list covers 20+ Git commands you’ll actually use in real projects, with one-line explanations so you know what they do and when to use them.

Core Git Commands Basics

1. `git init`

Creates a new Git repository in the current directory.

git init

2. `git clone`

Downloads an existing remote repository to your local machine.

git clone <repo-url>

3. `git status`

Shows the current state of files (modified, staged, untracked).

git status

4. `git add`

Stages files so they’re included in the next commit.

git add .
git add file.js

5. `git commit`

Saves staged changes as a snapshot with a message.

git commit -m "message"

6. `git push`

Uploads local commits to the remote repository.

git push origin main

7. `git pull`

Fetches remote changes and merges them into your branch.

git pull

Branching & Navigation

8. `git branch`

Lists branches or creates a new branch.

git branch
git branch feature-x

9. `git checkout`

Switches branches or restores files.

git checkout feature-x

10. `git switch`

A cleaner, modern way to switch branches.

git switch main

11. `git merge`

Combines another branch into the current branch.

git merge feature-x

12. `git log`

Shows commit history for the current branch.

git log --oneline --graph

Undoing Mistakes

13. `git reset`

Moves HEAD and optionally discards commits or changes.

git reset --soft HEAD~1
git reset --hard HEAD~1

14. `git revert`

Creates a new commit that safely undoes an older commit.

git revert <commit-hash>

15. `git checkout -- <file>`

Discards local changes to a specific file.

git checkout -- index.js

Temporary Work

16. `git stash`

Temporarily saves uncommitted changes.

git stash
git stash pop

17. `git stash list`

Shows all saved stashes.

git stash list

Working With Remotes

18. `git remote -v`

Displays configured remote repositories.

git remote -v

19. `git fetch`

Downloads remote changes without merging them.

git fetch

Inspecting Changes

20. `git diff`

Shows differences between files, commits, or stages.

git diff
git diff --staged

21. `git blame`

Shows who last modified each line of a file.

git blame file.js

22. `git show`

Displays detailed information about a specific commit.

git show <commit-hash>

Cleanup & Recovery

23. `git clean`

Removes untracked files from the working directory.

git clean -fd

24. `git reflog`

Shows every move of HEAD, even deleted or lost commits.

git reflog

How Senior Engineers Actually Use Git

Senior engineers:

check git status constantly,
prefer revert over reset on shared branches,
use fetch before risky merges,
rely on reflog when things go wrong.

Git isn’t just version control—it’s your safety net.

Final Thoughts

You don’t need to memorize Git.
You need to understand enough to recover when things break.

Master these commands and you’ll:

move faster,
panic less,
and collaborate better.

Git won’t make you a better engineer—but not knowing Git can absolutely make you a worse one.

Vibe Coding vs Engineering Judgment: Where Speed Ends and Responsibility Begins

Nilesh Raut — Wed, 14 Jan 2026 14:42:57 +0000

Right now, vibe coding is everywhere.

You prompt an AI, stay in flow, generate code quickly, and ship something that looks correct. Demos work. Tests pass. It feels productive.

And then production reminds you why engineering exists.

This post isn’t anti-AI. I use AI daily. But after working on real systems, handling incidents, and reviewing production code, one thing has become clear:

Vibe coding accelerates output. Engineering judgment protects systems.

You need both—but they solve very different problems.

What People Actually Mean by Vibe Coding

Vibe coding usually looks like this:

rapid AI-assisted code generation,
minimal planning,
trusting the output because “it works”,
prioritizing momentum over structure.

It’s popular because it removes friction. No blank page. No syntax struggles. No context switching.

For the right use cases, that’s a real advantage.

The problem starts when speed becomes the goal instead of correctness.

Why Vibe Coding Feels So Effective

Vibe coding works because it eliminates pain points developers hate:

staring at an empty file,
boilerplate work,
repetitive setup.

AI fills gaps instantly and keeps you moving. For small scopes, this is a genuine productivity boost.

But momentum without judgment doesn’t equal progress—it just means you’re moving fast in some direction.

Where Vibe Coding Works Well ✅

Let’s be honest about where vibe coding shines.

Disposable Prototypes

If the code will be thrown away—POCs, demos, experiments—vibe coding is ideal. Longevity doesn’t matter. Speed does.

Hackathons & Side Projects

When the goal is learning or validation, not production stability, vibe coding is a net win.

Boilerplate & Scaffolding

CRUD APIs, basic UI layouts, config setup—AI handles these well and saves real time.

In all these cases, the cost of mistakes is low.

Where Vibe Coding Fails ❌

This is where experience matters.

Large, Long-Lived Systems

Code that must survive:

multiple teams,
refactors,
scaling,
years of maintenance.

AI-generated structure often looks clean early and becomes painful later.

Security-Critical Code

Auth, permissions, payments, secrets.
Vibe coding here is risky because insecure defaults don’t fail loudly—they fail later.

Complex Business Logic

Business rules are messy and full of exceptions. AI tends to simplify them incorrectly and encode assumptions that break in edge cases.

A Real Mistake I Made Using Vibe Coding

I once used AI to quickly implement a background job flow. It worked perfectly in staging. Clean retries. Nice abstractions.

What I missed:

retries weren’t idempotent,
partial failures caused duplicate writes,
logs hid the real issue.

It took a production incident to uncover it.

The AI didn’t make the mistake.
I did—by trusting speed over judgment.

How Much Vibe Coding Is Too Much?

A simple rule that works:

If you can’t explain why the code is safe, you shouldn’t ship it.

AI can help write code.
Only humans can own the consequences.

Use AI as:

an assistant,
a drafting tool,
a productivity multiplier.

Not as the architect or decision-maker.

Security Risks Are the Quiet Problem

The biggest danger of vibe coding isn’t broken code—it’s unquestioned code.

Common issues:

hardcoded secrets “temporarily” left in place,
overly permissive access checks,
unsafe dependency choices,
missing validation paths.

Everything looks fine until it isn’t.

Security requires skepticism. AI doesn’t have that instinct.

Best Practices for Safe Vibe Coding

What’s worked for me:

Slow down at boundaries (auth, data writes, integrations)
Review AI code as if someone else wrote it
Ask how it fails, not just how it works
Never skip human code review
Treat AI output as untrusted by default

Speed without discipline just moves problems downstream.

Final Verdict

Vibe coding isn’t bad.
Blind vibe coding is.

Use vibe coding to:

explore ideas,
reduce friction,
move fast where risk is low.

Rely on engineering judgment to:

protect users,
secure systems,
design for failure,
own production outcomes.

Speed ships features. Judgment keeps systems alive.

That’s the difference experience teaches you.

How Video Platforms Show Instant Hover Previews Using Sprite Sheets in Node.js

Nilesh Raut — Mon, 12 Jan 2026 15:07:48 +0000

If you’ve ever hovered over a video timeline and seen preview images change instantly, you’ve already interacted with sprite sheets—even if you didn’t know what they were called.

Those previews aren’t loaded one image at a time. That approach would be slow, expensive, and unreliable once traffic grows. Instead, the application loads one image and reuses it efficiently.

Sprite sheets are still one of the most practical ways to build fast, interactive image previews, especially for video platforms, dashboards, and media-heavy applications where user interaction needs to feel instant.

A Real-World Example: Video Timeline Hover

Think about how video platforms handle timeline previews.

As you move your cursor across the progress bar:

preview frames update immediately,
there’s no visible loading,
network activity doesn’t spike.

What’s happening behind the scenes is simple and effective. The frontend loads a single sprite sheet image ahead of time. As the user scrubs through the timeline, the UI just changes which part of that image is visible. After the initial load, the network is no longer involved.

That’s why the interaction feels smooth and predictable.

What a Sprite Sheet Actually Is

A sprite sheet is a single image that contains many smaller images arranged in a grid.

Here’s an example of a real sprite sheet generated from a video, showing how multiple preview frames are packed into a single image.

Instead of loading multiple files like:

thumb_01.jpg
thumb_02.jpg
thumb_03.jpg

the application loads:

spritesheet.jpg

The frontend then displays only the relevant section of that image using simple position calculations. No additional image requests are required during interaction.

Why Sprite Sheets Still Matter

Even with HTTP/2, CDNs, and faster networks, sprite sheets solve problems that haven’t gone away:

they drastically reduce the number of image requests,
hover interactions feel instant,
backend load stays predictable,
caching works extremely well.

For interactive previews, removing the network from the critical interaction path makes a noticeable difference in user experience.

Backend Responsibilities (Node.js)

The backend should never generate preview images on demand.

In a production setup, the backend is responsible for:

generating sprite sheets asynchronously,
storing them as static assets,
exposing metadata that describes how the sprite sheet is structured.

Sprite generation typically runs in background jobs or media pipelines, not inside API request handlers.

Example Sprite Metadata

{
  "spriteUrl": "/sprites/video_101.jpg",
  "frameWidth": 160,
  "frameHeight": 90,
  "columns": 5,
  "rows": 4,
  "intervalSeconds": 2
}

This metadata is what allows the frontend to correctly calculate which frame to show at any given time.

Simple Node.js Backend Example

Here’s a minimal Express setup that exposes sprite metadata and serves the sprite image as a static asset.

const express = require("express");
const sharp = require("sharp");
const app = express();

app.use("/sprites", express.static("sprites"));
// Upload video to generate the sprites sheet of that image 
app.post("/upload", upload.single("video"), (req, res) => {
  const videoPath = req.file.path;
  const videoName = path.parse(req.file.originalname).name;
 const thumbnailsDir = `thumbnails/${videoName}`;
  const spriteOutput = `sprites/${videoName}.jpg`;

  fs.mkdirSync(thumbnailsDir, { recursive: true });

  // 1. Extract frames every 2 seconds
  const extractCmd = `
    ffmpeg -i ${videoPath} -vf fps=1/2 ${thumbnailsDir}/thumb_%03d.jpg
  `;

  exec(extractCmd, (err) => {
    if (err) {
      console.error("Frame extraction failed:", err);
      return;
    }
   const files = fs.readdirSync(thumbnailsDir);

    const frameWidth = 160;
    const frameHeight = 90;
    const columns = 5;
    const rows = Math.ceil(files.length / columns);

    const spriteWidth = frameWidth * columns;
    const spriteHeight = frameHeight * rows;

    const compositeImages = files.map((file, index) => {
      const col = index % columns;
      const row = Math.floor(index / columns);

      return {
        input: path.join(thumbnailsDir, file),
        left: col * frameWidth,
        top: row * frameHeight
      };
    });

    await sharp({
      create: {
        width: spriteWidth,
        height: spriteHeight,
        channels: 3,
        background: "#000"
      }
    })
      .composite(compositeImages)
      .jpeg({ quality: 80 })
      .toFile(spriteOutput);

    console.log("Sprite sheet created:", spriteOutput);
// Store the generated sprite sheet in object storage (e.g. S3, GCS)
// and save the sprite URL + frame metadata with the video record
  });

  res.json({
    message: "Video uploaded successfully. Sprite generation started."
  });
});


app.get("/api/video/:id/sprite", (req, res) => {
//add your own logic to how to acces the new genrated image eg store in to s3 storage any where and return the url of image 
  res.json({
    spriteUrl: "/sprites/video_101.jpg",
    frameWidth: 160,
    frameHeight: 90,
    columns: 5,
    rows: 4,
    intervalSeconds: 2
  });
});

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

This approach scales cleanly because the backend only serves metadata and static files. The heavy work happens elsewhere.

Frontend Handling (Plain JavaScript)

On the frontend, the logic is straightforward:

fetch the sprite metadata,
load the sprite image once,
update the visible frame based on cursor position.

HTML

<div id="timeline"></div>
<div id="preview"></div>

JavaScript

const preview = document.getElementById("preview");
const timeline = document.getElementById("timeline");

fetch("/api/video/101/sprite")
  .then(res => res.json())
  .then(data => {
    preview.style.backgroundImage = `url(${data.spriteUrl})`;

    const {
      frameWidth,
      frameHeight,
      columns,
      intervalSeconds
    } = data;

    timeline.addEventListener("mousemove", (e) => {
      const rect = timeline.getBoundingClientRect();
      const percent = (e.clientX - rect.left) / rect.width;

      const videoDuration = 120; // seconds
      const hoverTime = percent * videoDuration;

      const frameIndex = Math.floor(hoverTime / intervalSeconds);
      const col = frameIndex % columns;
      const row = Math.floor(frameIndex / columns);

      preview.style.backgroundPosition =
        `-${col * frameWidth}px -${row * frameHeight}px`;
    });
  });

Once the sprite image is loaded, preview updates happen entirely on the client, with no additional network calls.

Common Mistakes to Avoid

Some issues show up repeatedly in real projects:

generating sprite sheets synchronously in API requests,
hardcoding frame sizes on the frontend,
creating very large sprite sheets that hurt mobile performance,
treating sprite sheets as a frontend-only concern.

Sprite sheets work best when backend and frontend agree on a clear contract.

Final Thoughts

Sprite sheets aren’t outdated or hacky. They’re a practical performance pattern that still works because it removes the network from user interactions.

If you’re building:

video players,
hover previews,
timeline scrubbing features,

sprite sheets remain one of the cleanest solutions available when implemented intentionally.

I write more content like this on nileshblog.tech if you want to explore further.

Designing APIs That Are Hard to Misuse

Nilesh Raut — Sat, 10 Jan 2026 18:30:00 +0000

Most backend bugs don’t happen because developers are careless.
They happen because APIs are easy to misuse.

If an API allows the wrong thing, someone will eventually do it — intentionally or not. Senior engineers know this, and they design APIs that guide correct usage and make incorrect usage difficult.

This post is about how experienced engineers think when designing APIs that survive real-world use.

The Core Principle: Assume Misuse, Not Malice

When designing an API, don’t assume:

consumers will read the docs carefully,
inputs will always be valid,
calls will be made in the correct order.

Assume instead:

someone will misunderstand it,
someone will skip validation,
someone will copy-paste an example without thinking.

A good API doesn’t rely on “being used correctly.”
It enforces correctness by design.

Clear Inputs, Clear Outputs

Ambiguous APIs invite misuse.

Bad example:

POST /updateUser

What does this update?

name?
email?
password?
all of them?

Better:

PATCH /users/{id}/email

Now:

the intent is clear,
the scope is limited,
misuse becomes harder.

If an API endpoint can do “too many things,” it will eventually do the wrong one.

Make Invalid States Impossible

Senior engineers try to design APIs where invalid states cannot exist.

For example, instead of:

{
  "status": "active",
  "deleted": true
}

Design it so:

a user cannot be both active and deleted,
the API does not accept conflicting inputs.

If your API allows contradictory data, the bug isn’t in the client — it’s in the design.

Use Explicit Errors, Not Silent Defaults

Silent behavior is dangerous.

Bad design:

missing field → default value applied
invalid input → ignored
partial failure → success response

This makes bugs invisible.

Better design:

reject invalid input loudly,
return clear error messages,
fail fast and early.

APIs should teach consumers how to use them correctly through errors.

Avoid “Magic” Behavior

Magic APIs feel convenient at first — and painful later.

Examples of magic behavior:

auto-creating resources without saying so,
silently retrying without limits,
changing behavior based on hidden flags.

If something important happens, make it explicit.

Good APIs are boring.
Boring APIs are predictable.

Idempotency Matters More Than You Think

In real systems:

requests get retried,
clients time out,
networks fail.

If calling an API twice causes unintended side effects, it will break in production.

Design APIs so:

repeated requests are safe,
duplicate calls don’t corrupt state,
clients don’t need complex retry logic.

This alone prevents many production incidents.

Design for the Future Consumer

The person using your API in six months:

might not be you,
might not know the context,
might be under pressure.

Ask yourself:

Can this API be misunderstood?
Can it be called in the wrong order?
Can misuse cause data corruption?

If the answer is “yes,” redesign.

A Real-World Example

Many production bugs come from APIs like:

POST /processPayment

Called twice → double charge.

A better design:

separate intent from execution,
require idempotency keys,
make side effects explicit.

The extra effort up front saves incidents later.
🔗 Check out our blog site for more: nileshblog.tech

Final Takeaway

APIs are contracts, not just endpoints.

A well-designed API:

limits what can go wrong,
makes correct usage obvious,
makes incorrect usage difficult,
protects the system from human error.

Senior engineers don’t just design APIs that work —
they design APIs that are hard to misuse.