Forem: Nilesh Raut

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.

Stateless vs Stateful Services

Nilesh Raut — Tue, 06 Jan 2026 18:30:00 +0000

This is one of those backend topics everyone thinks they understand — until production proves otherwise.

On paper, stateless sounds “better.”
In reality, both stateless and stateful services exist for good reasons. Problems start when we pick one without understanding the trade-offs.

Let’s break this down the way it actually shows up in real systems.

What Does “Stateless” Really Mean?

A stateless service does not store client-specific data between requests.

Each request:

Is independent
Contains everything the server needs
Can be handled by any instance

Simple Example

GET /users/123

The server:

Reads user data from a database
Returns the response
Forgets everything about the request

No memory of who you are. No session stored on the server.

Real-World Examples

REST APIs
Public HTTP services
Authentication using JWT tokens
Read-heavy backend services

What Does “Stateful” Actually Mean?

A stateful service remembers something about the client between requests.

That “state” could be:

Session data
In-memory cache
User progress
Open connections

Simple Example

Login → Session created → Session reused on next request

The server remembers you.

Real-World Examples

Login sessions stored in memory
WebSocket connections
Multiplayer game servers
In-memory queues
Stateful stream processors

The Key Difference (In One Line)

Stateless → “Every request is new.”
Stateful → “I remember you.”

That single difference impacts scaling, reliability, and debugging.

Why Stateless Services Are Easier to Scale

Stateless services scale beautifully.

Why?

Any instance can handle any request
Load balancers don’t care where traffic goes
Crashed instances don’t lose user data

Example

You have 5 backend servers behind a load balancer.

If one goes down:

Traffic shifts to others
No user impact
No recovery logic

This is why stateless services dominate modern backend design.

Why Stateful Services Still Exist (And Always Will)

Despite the hype, stateless is not always the right choice.

Stateful services exist because:

Some data is expensive to recompute
Some interactions require continuity
Some systems depend on long-lived connections

Example: WebSockets

A chat server maintains:

Open connections
Message state
User presence

Trying to make that fully stateless often makes things worse, not better.

Real Production Example: Session Handling

❌ Stateful (Problematic)

Session stored in server memory
User logs in
Load balancer sends next request to another server
Session not found → user logged out

This breaks immediately at scale.

✅ Better Approach

Stateless backend
Session stored in Redis or DB
Any instance can validate session

You still have state, but it’s externalized, not tied to a single instance.

Common Mistake: Confusing “Stateless” With “No State”

Stateless does not mean:

No database
No cache
No user data

It means:

The service instance does not own the state.

The state lives somewhere else.

Debugging Differences (Very Real)

Stateless Debugging

Easier reproduction
Restart fixes many issues
Horizontal scaling is safe

Stateful Debugging

Bugs depend on order of requests
Restart may lose critical data
Harder to reproduce locally

This is why stateful bugs feel “random” in production.

When Stateless Is the Right Choice

Use stateless services when:

You’re building HTTP APIs
You expect traffic spikes
You need easy horizontal scaling
You want safer deployments

If you’re unsure, default to stateless.

When Stateful Is the Right Choice

Stateful services make sense when:

You need real-time connections
You maintain long-lived sessions
Performance depends on in-memory state
The cost of externalizing state is too high

The key is being intentional.

Final Takeaway

Stateless vs stateful is not a debate — it’s a design decision.

Stateless services optimize for scalability and resilience
Stateful services optimize for continuity and performance

Most modern systems:

Keep services stateless
Push state to databases, caches, or message systems
Accept statefulness only where it truly adds value

If you understand this distinction clearly, you’ll avoid a whole class of backend failures before they ever reach production.

How to Review AI-Written Code Like a Engineer

Nilesh Raut — Sat, 03 Jan 2026 05:56:39 +0000

AI can generate code incredibly fast.
Sometimes fast enough to make you pause and think, “Did this just replace half my work?”

But speed has never been the hard part of engineering.

The real challenge is making sure the code:

does the right thing,
fails safely,
can be understood later,
and won’t hurt you in production.

That’s why reviewing AI-written code requires a slightly different mindset than reviewing human code. The mistakes are subtler, the confidence is misleading, and the risks are easy to underestimate.

This post walks through how engineers actually review AI-generated code in real projects — not in demos, not in theory.

Start With the Right Mindset

The most important rule is simple:

Treat AI-written code as a first draft, not a solution.

It may compile.
It may pass basic tests.
It may even look clean.

That doesn’t mean it’s correct, safe, or appropriate for your system.

engineers don’t ask “Does this work?”
They ask “Should this exist in this form?”

Step 1: Understand the Intent Before the Code

Before reading the implementation, step back and ask:

What problem is this code supposed to solve?
What are the inputs and expected outputs?
What guarantees does it claim to provide?

This matters because AI often solves the prompt, not the real requirement.

If you can’t explain the intent clearly in your own words, reviewing the code line by line is pointless. Misaligned intent leads to clean-looking but wrong solutions.

Step 2: Think About Failure, Not Success

AI code usually handles the happy path well.
That’s not where production issues come from.

Ask questions like:

What happens with empty or invalid input?
What happens under load?
What happens when a dependency slows down or fails?
What happens if this function is called in an unexpected order?

engineers always look for failure modes first. If the code has no obvious way to fail, that’s usually a bad sign.

Step 3: Look for Silent Assumptions

AI is very good at making assumptions — and very bad at documenting them.

Common ones include:

This value is never null
This list is always sorted
This function is only called once
This service is always fast

Any time the logic depends on something always being true, stop and verify where that guarantee comes from. Many real production bugs are just assumptions that stopped being true over time.

Step 4: Review Security Before Style 🔐

Clean code doesn’t matter if it’s unsafe.

Before commenting on formatting or naming, check:

Are authorization checks present?
Is user input validated?
Is sensitive data protected?
Are defaults safe?

AI-generated code often looks professional while quietly skipping security boundaries. If the code touches authentication, payments, or user data, it deserves extra scrutiny.

Security issues are expensive because they don’t always fail loudly.

Step 5: Check the Level of Complexity

AI tends to either:

over-engineer simple problems, or
under-engineer complex ones.

Look for:

unnecessary abstractions,
premature generalization,
hardcoded behavior that limits future change.

Ask yourself: Is this complexity solving a real problem today, or just adding mental overhead?
engineers value clarity over cleverness.

Step 6: Read It Like You’ll Own It Long-Term

A useful mental trick is to ask:

Would I be comfortable debugging this at 2 AM?
Would a new teammate understand this without context?
Are names honest and specific?
Are side effects obvious?

AI code often uses generic naming and hides behavior in ways that feel fine at first but become painful later. If something feels hard to reason about now, it will only get worse with time.

Step 7: Check Observability

When this code fails in production, how will you know?

Look for:

meaningful logs,
useful error messages,
signals that point to the real problem.

Silent failures are dangerous. Good code doesn’t just fail — it explains why.

Step 8: Don’t Trust Without Tests

Never approve AI-written code without tests.

Check whether tests:

cover edge cases,
assert behavior instead of implementation,
fail for the right reasons.

Tests are not just about correctness — they’re future documentation for how this code is expected to behave when things go wrong.

Step 9: Decide What to Keep and What to Rewrite

engineers don’t treat AI output as all-or-nothing.

Often the best outcome is:

keep the structure,
rewrite critical logic,
simplify what doesn’t need to be clever.

AI is a productivity accelerator, not an authority. You’re still responsible for the final shape of the code.

🔗 Read the full write-up on reviewing AI-written code like a engineer

A Practical Rule of Thumb

Many experienced engineers follow something like this:

AI for scaffolding → ✅
AI for non-critical logic → ⚠️
AI for security-sensitive paths → ❌ without deep review

The more critical the code, the more human ownership it requires.

Why This Skill Matters More Every Year

As AI writes more code:

codebases grow faster,
context becomes thinner,
risk increases quietly.

The engineers who stand out won’t be the ones who generate the most code. They’ll be the ones who can look at confident-looking solutions and say, “This feels right, but it’s actually wrong.”

That’s judgment.

Final Thoughts

AI doesn’t remove responsibility — it concentrates it.

If you approve AI-written code, you own it:

in production,
during incidents,
in audits,
and in postmortems.

Review it carefully.
Question it calmly.
Improve it deliberately.

AI can help you write code faster.
Engineering judgment is what makes it safe.

Why Debugging Skills Matter More Than Writing New Code

Nilesh Raut — Sat, 27 Dec 2025 10:34:45 +0000

The Moment Every Developer Recognizes

Writing new code feels productive.
Debugging feels slow, frustrating, and invisible.

Yet the most stressful moments in a developer’s career rarely involve writing something new. They involve a system that already exists and is behaving in ways no one expected.

Production doesn’t break because of missing features.
It breaks because of misunderstood ones.

New Code Is Easy. Broken Code Is Reality.

Most developers are trained to:

Build features
Follow patterns
Write clean abstractions

But real-world systems are:

Stateful
Distributed
Full of edge cases
Running code written by many people over many years

At some point, every engineer realizes that writing new code is a smaller part of the job than keeping existing code working.

Debugging Is How You Learn the System

Debugging forces you to answer uncomfortable questions:

Why does this exist?
What assumptions were made?
What happens if this fails?
Who depends on this behavior?

You can write new code without understanding the system.
You cannot debug effectively without understanding it.

That’s why great debuggers ramp up faster on new teams — they learn the system by following its failures.

Debugging Builds Engineering Intuition

Over time, debugging teaches you patterns you can’t get from tutorials:

Race conditions
Partial failures
Misconfigured environments
“Works locally” production bugs

Strong debuggers don’t panic when things break.
They form hypotheses, test them, and narrow the problem space.

That mindset matters more than syntax mastery.

Production Doesn’t Care How Clean Your Code Is

In production:

Logs lie or are missing
Metrics are noisy
Errors cascade
Small changes cause large failures

Debugging teaches you how systems behave under stress.

This is why senior engineers are often pulled into incidents — not because they write faster, but because they reason better when things go wrong.

Debugging Improves Your Future Code

Developers who debug a lot start writing different code:

Better logs
Clearer error messages
Safer defaults
Fewer assumptions

Debugging feedback loops improve design.

If you never feel the pain of broken code, you don’t learn how to prevent it.

Why Debugging Skills Matter More Than Writing New Code : NileshBlog.Tech

Debugging skills matter more than writing new code. Learn why real-world production issues, war stories, and a practical checklist shape better software engineers.

nileshblog.tech

Why Debugging Skills Age Better Than Languages

Languages change.
Frameworks come and go.
Tooling evolves constantly.

But debugging skills transfer:

Across languages
Across stacks
Across companies

If you can:

Read logs
Trace execution
Understand failure modes
Ask the right questions

You can survive almost any tech stack.

Read the full article with real production war stories and a debugging checklist

A Real Career Difference

Junior engineers often ask:

“What should I learn next?”

My honest answer is rarely a new framework.

It’s:

Learn how to debug production issues
Learn how to read logs and metrics
Learn how to reason about failures

Those skills compound over time.

Writing Code Feels Like Progress. Debugging Is Progress.

New code gets attention.
Debugging gets results.

Great engineers aren’t defined by how much code they write — but by how reliably they can fix what’s already running.

Final Thought

If you want to grow faster as a developer, stop optimizing for:

Writing more code
Learning more frameworks
Shipping faster at any cost

Start optimizing for:

Understanding failures
Investigating weird behavior
Debugging calmly under pressure

Debugging is where real engineering skill shows up.

How Much DevOps Knowledge Is Actually Required for an SDE?

Nilesh Raut — Mon, 22 Dec 2025 18:30:00 +0000

The Question Every Developer Eventually Asks

At some point in your career, it happens.

Your code works locally.
Tests pass.
The PR gets approved.

Then someone says:

“It broke in production.”

Suddenly you’re staring at logs, pipelines, dashboards, YAML files, and thinking:

“Wait… how much DevOps am I actually expected to know as an SDE?”

This question comes up constantly. As teams move faster and ownership shifts left, the line between dev and ops keeps getting blurrier. The short answer: more than before, less than a DevOps engineer.

The long answer is where real-world experience matters.

The Old Model vs. Today’s Reality

The Old World (Mostly Gone)

Earlier, responsibilities were clear:

Developers wrote code
Ops deployed and ran it
Production issues were “someone else’s problem”

That worked when releases were slow and systems were simpler.

The World We Actually Work In

Today:

CI/CD is automatic
Systems are distributed
Failures are expected
Teams own services end to end

Even if your title says Software Development Engineer, production doesn’t care.

What DevOps Knowledge Is Not Required

Let’s clear some confusion.

As an SDE, you are not expected to:

Design Kubernetes clusters from scratch
Be an expert in Terraform modules
Tune networking or kernel internals
Fully replace a DevOps/SRE team

The Minimum DevOps Knowledge Every SDE Should Have ✅

This is the baseline I’ve seen across healthy engineering teams.

1. Deployment Awareness

You should know:

How your service gets deployed
What happens after you merge to main
Where to look when deployments fail

You don’t need to build pipelines — but you must understand them.

2. Logging & Monitoring

If your code runs in production, you should know:

Where logs are stored
How to search and filter them
What “normal” vs “broken” looks like

If you can’t debug your own service, someone else will — and they won’t be happy about it.

3. Basic Cloud & Container Concepts

You don’t need deep expertise, but you should understand:

What containers are
Why environment variables matter
What scaling actually means
Why stateless services are preferred

This is table-stakes knowledge now.

4. CI/CD Basics

You should be comfortable:

Reading pipeline configs
Understanding failed builds
Knowing when a rollback is required

Pipelines are part of the codebase. Ignoring them isn’t an option.

Kubernetes: How Deep Should You Go?

You don’t need to become a Kubernetes expert overnight.

But as an SDE, it helps to understand:

What Pods, Services, and Deployments are
How your app is exposed
How config and secrets are injected
How crashes and restarts work

If you want a structured, developer-friendly way to learn this, I’ve documented my own journey here:
👉 30 Days of Kubernetes for Backend Developers
https://nileshblog.tech/category/backend-dev/kubernetes/30-days-kubernetes/

It’s written from a developer’s perspective — not an infra-first one — and focuses on just enough Kubernetes to be effective.

A Real Mistake I Made Early On

Early in my career, I treated deployments as “not my responsibility.”

My service deployed automatically, so I never checked the pipeline. One day, a config change caused the app to crash-loop in production.

The logs clearly explained the issue.

I just didn’t know where to find them.

What I learned:

If you write the code, you own how it behaves
DevOps knowledge isn’t about control — it’s about responsibility
Learning the basics is cheaper than debugging blindly

That mistake permanently changed how I approach production.

How DevOps Expectations Scale With Seniority

Junior SDE

Understand deployments conceptually
Read logs and metrics
Fix CI-related failures

Mid-Level SDE

Debug production issues independently
Understand scaling and configuration
Make small infra or pipeline changes

Senior SDE

Design services with operability in mind
Review infra changes safely
Mentor others on production readiness

Notice the pattern?

Depth increases — scope doesn’t.

You don’t become a DevOps engineer.
You become a more production-aware engineer.

Final Verdict

So how much DevOps knowledge is required for an SDE?

Enough to:

Own your code in production
Debug issues confidently
Collaborate effectively with DevOps/SRE teams

Not enough to:

Replace DevOps engineers
Run infrastructure alone
Burn out doing two jobs

DevOps knowledge isn’t about role overlap — it’s about shared responsibility.

If you can ship code and understand what happens after shipping, you’re exactly where you should be.

💬 Discussion

How much DevOps knowledge is expected in your current role?
And where do you think the line should be?

Forem: Nilesh Raut

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

First: Kubernetes Doesn’t “Deploy” Your Code

What Happens After You Merge a PR

Step 1 — PR is merged

Step 2 — CI/CD pipeline runs

Step 3 — Deployment is triggered

What Kubernetes Actually Does Next

Important: What Actually Triggers a Rollout

Small System vs Microservices: What Changes?

Small System (Single Service)

Microservices (Real World)

Real Production Mistakes I’ve Seen

1. Memory limit reduced “just a little”

2. ConfigMap updated but pods didn’t restart

3. Using latest tag

Security Awareness in Deployment

The Real Engineering Mindset

Final Thought

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

1. Your Local Machine Is Lying to You

2. Database Latency Is the Silent Killer

3. Connection Pooling Misconfigurations

4. Blocking the Event Loop (Without Realizing It)

5. Missing Timeouts Everywhere

6. Logging Becomes a Performance Problem

7. Scaling Without Understanding Throughput

8. You’re Not Testing Production-Like Load

Final Thoughts

Idempotency: The Concept Everyone Mentions but Few Implement Correctly

What Idempotency Actually Means (Beyond the Definition)

Where Idempotency Matters (and Where It Doesn’t)

Common places it does matter

Places it usually doesn’t

The Biggest Misconception: “POST Is Not Idempotent”

The Naive (and Wrong) Implementations

1. “We Just Retry”

2. “We Check If It Exists”

3. “We Use a Boolean Flag”

The Correct Mental Model

Idempotency Keys: The Foundation

A Minimal, Correct Implementation

Step 1: Store the key

Step 2: Enforce uniqueness

Step 3: On request

Handling Partial Failures (The Hard Part)

Real-World Example: Payments

Performance and Storage Trade-offs

Security Considerations

Final Thoughts

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

Why Redis Is Not a Database (By Default)

The Common Trap: “It’s Just Temporary”

Persistence: The First Reality Check

RDB (Snapshots)

AOF (Append-Only File)

AOF + RDB

Redis Without Backups Is a Risk, Not a System

Concurrency: Redis Is Atomic, Not Magical

When Redis Can Act Like a Database

Small Systems vs Large Systems

Small Systems

Large Systems

Mental Model That Actually Works

Final Thoughts

20+ Git Commands Every Software Engineer Should Actually Know

Core Git Commands Basics

1. git init

2. git clone

3. git status

4. git add

5. git commit

6. git push

7. git pull

Branching & Navigation

8. git branch

9. git checkout

10. git switch

11. git merge

12. git log

3. Using `latest` tag

1. `git init`

2. `git clone`

3. `git status`

4. `git add`

5. `git commit`

6. `git push`

7. `git pull`

8. `git branch`

9. `git checkout`

10. `git switch`

11. `git merge`

12. `git log`

13. `git reset`

14. `git revert`

15. `git checkout -- <file>`

16. `git stash`

17. `git stash list`

18. `git remote -v`

19. `git fetch`

20. `git diff`

21. `git blame`

22. `git show`

23. `git clean`

24. `git reflog`