Forem: CodeWithIshwar

🚨 Java & JavaScript Are NOT Call by Reference

CodeWithIshwar — Wed, 15 Apr 2026 17:16:28 +0000

This is one of those concepts that seems obvious… until it breaks your code.

Many developers believe:

“Objects are passed by reference in Java or JavaScript”

❌ That’s incorrect.

👉 Both Java and JavaScript are strictly call by value

🧠 Why This Feels Wrong

If you’ve ever done this:

function update(user):
    user.name = "Ishwar"

…and seen the change reflected outside,
it feels like pass by reference.

But then this:

function reset(user):
    user = new Object()

Does nothing to the original.

So what’s really going on?

⚙️ What’s Actually Happening

Variables store values
For objects → that value is a reference (memory address)

👉 When calling a function:

A copy of that value is passed
Not the original variable

🔍 The Key Insight

Inside the function:

You get a copy of the reference
Both point to the same object → mutation works
But reassignment only affects the local copy

🔁 Mental Model

original variable → copy value → function parameter

👉 You never get direct access to the original variable

📦 Stack vs Heap (Quick View)

Stack → variables (copies live here)
Heap → actual objects

👉 You copy the reference value, not the object

🌍 Applies Beyond Just Java

Language	Behavior
Java	Call by Value
JavaScript	Call by Value
Python	Call by Value (object ref)
C#	Call by Value (default)

💡 Final Takeaway

Everything is pass by value.
Some values just happen to be references.

🚀 Why This Matters

This concept shows up in real-world bugs:

Unexpected object mutations
State issues in frontend apps
Backend data inconsistencies
API transformation bugs

🤔 Discussion

When did this finally click for you?

Early learning phase
On the job
Or after debugging something painful 😅

Built for devs who like understanding why, not just what.
More deep dives coming.

🚨 Java & JavaScript Are NOT Call by Reference (Let’s Break This Myth)

CodeWithIshwar — Wed, 15 Apr 2026 17:14:43 +0000

One of the most common misconceptions in programming:

“Objects are passed by reference in Java or JavaScript”

❌ That’s not true.

👉 Both Java and JavaScript are call by value

🧠 Why the Confusion?

Because when you pass objects into a function, changes sometimes reflect outside.

That behavior feels like call by reference… but it’s not.

⚙️ What Actually Happens

Every variable stores a value
For primitives → actual data
For objects → memory address (reference)

👉 During a function call:
➡️ A copy of that value is passed

🔍 Two Cases That Explain Everything

✅ Case 1: Mutation (Works)

function change(user) {
  user.name = "Ishwar"; // ✅ affects original
}

✔️ Both variables point to the same object in memory
✔️ Changes are visible

❌ Case 2: Reassignment (Does NOT Work)

function reassign(user) {
  user = { name: "New" }; // ❌ does NOT affect original
}

❌ Only the local copy changes
❌ Original remains unchanged

⚙️ The Algorithm Behind It

Variable stores a value
Function is called
A new stack frame is created
Parameters receive copy of argument values
Function works on copied values
Stack frame is destroyed

🔁 Mental Model

Caller Variable → Copy Value → Function Parameter

👉 No direct access to original variable
👉 Only a copy is used

📦 Stack vs Heap (Simple View)

Stack → variables (copies live here)
Heap → actual objects

👉 You copy the reference value, not the object

🌍 Applies to Multiple Languages

Language	Behavior
Java	Call by Value
JavaScript	Call by Value
Python	Call by Value (object ref)
C#	Call by Value (default)

💡 Final Rule

“Everything is pass by value.
Some values just happen to be references.”

🚀 Why This Matters

This concept helps avoid bugs in:

Backend APIs
State management (React, Redux)
Object mutation issues
System design

🤔 Question for You

When did this concept finally click for you?

College?
First job?
Or after debugging a weird bug? 😅

💬 If this helped, drop a comment or share with someone who still thinks it's call by reference 😉

#java #javascript #programming #coding #softwareengineering #webdev #beginners #devtips

Limitations of System Design with Real-World Examples

CodeWithIshwar — Mon, 13 Apr 2026 17:50:07 +0000

System design looks clean in theory.

But real systems are built on trade-offs.

1. No Design is Future-Proof

Netflix started with a monolith and later moved to microservices as scale increased.

2. Trade-offs are Unavoidable

Amazon often prefers availability over strict consistency.

Users may see "Order Placed" even if systems are still syncing.

3. Over-Engineering Slows You Down

Microservices too early can slow development.

4. Assumptions Fail

Uber had to redesign systems as demand patterns changed.

5. Cost vs Performance

Better performance requires more infrastructure cost.

6. Complexity Increases with Scale

More services lead to more failures and harder debugging.

Final Thought

There is no perfect system design. Only trade-offs.

Limitations of System Design (with Real-World Examples)

CodeWithIshwar — Mon, 13 Apr 2026 17:48:26 +0000

System design often looks clean in theory — neat diagrams, scalable architectures, and well-defined components.

But in real-world systems, things are rarely that simple.

Every design decision comes with trade-offs.

🚫 1. No Design is Future-Proof

Systems evolve with scale.

Example:
Netflix started with a monolithic architecture and later moved to microservices as its user base grew.

Takeaway: Design for current needs, but expect change.

⚖️ 2. Trade-offs Are Unavoidable

You cannot optimize everything at once.

Example:
Amazon often prioritizes availability over strict consistency. Users may see "Order Placed" even when backend systems are still syncing.

Takeaway: User experience > perfect consistency (sometimes).

⚡ 3. Over-Engineering Slows You Down

Microservices are powerful—but not always necessary.

Common mistake:
Teams adopt microservices too early, increasing complexity and slowing development.

🔄 4. Assumptions Don’t Hold Forever

System design relies on assumptions:

Traffic patterns
User behavior
Growth

Example:
Uber had to redesign parts of its system as demand patterns evolved.

💰 5. Cost vs Performance

Improving performance comes at a cost:

Caching
CDNs
Replication

Better performance = higher cost.

🧩 6. Complexity Increases with Scale

As systems grow:

More services
More communication
More failure points

Debugging distributed systems is harder than building them.

🎯 Final Thoughts

There is no perfect system design.

Only trade-offs, constraints, and context.

👉 Design for today. Prepare for tomorrow.

💬 Discussion

What’s one system design challenge you’ve faced?

Most developers use indexes. Very few truly understand how they work.

CodeWithIshwar — Sun, 12 Apr 2026 16:27:08 +0000

Most developers use indexes. Very few truly understand how they work

I’ve seen developers with years of experience write queries that scan millions of rows… Not because they lack skill. But because they don’t truly understand indexes.

linkedin.com

Most developers use indexes. Very few truly understand how they work

CodeWithIshwar — Sun, 12 Apr 2026 16:26:05 +0000

Most developers use indexes. Very few truly understand how they work

I’ve seen developers with years of experience write queries that scan millions of rows… Not because they lack skill. But because they don’t truly understand indexes.

linkedin.com

Most developers use indexes. Very few truly understand how they work https://www.linkedin.com/pulse/most-developers-use-indexes-very-few-truly-understand-tiwari-wdtlc/

CodeWithIshwar — Sun, 12 Apr 2026 16:25:35 +0000

Most developers use indexes. Very few truly understand how they work

I’ve seen developers with years of experience write queries that scan millions of rows… Not because they lack skill. But because they don’t truly understand indexes.

linkedin.com

🌐 What Actually Happens When You Type a URL? (DNS Breakdown)

CodeWithIshwar — Fri, 10 Apr 2026 17:55:33 +0000

We type URLs every day.

But what actually happens when you enter something like:

www.google.com ?

🔁 The DNS Resolution Flow

Your system doesn’t know the IP address directly. It follows a lookup process:

1. Local Cache

First stop:

Browser cache
OS cache

👉 If the IP is already known → instant response

2. DNS Resolver

If not found, the request goes to a DNS resolver (ISP or public DNS).

3. Hierarchical Lookup

The resolver queries step by step:

Root server → points to .com
TLD server → points to google.com
Authoritative server → returns actual IP

4. Caching (TTL)

The result is cached for future use.

👉 This is why repeat requests feel fast.

🧠 What’s Interesting Here?

DNS isn’t just a simple lookup.

It combines:

Tree traversal
Recursive + iterative queries
Aggressive caching
Efficient internal data structures

⚡ Why It Feels Instant

Without caching:

Multiple network hops per request

With caching:

Near constant-time lookup

👉 That’s the real performance trick.

🚨 Real-World Perspective

DNS is one of those systems you don’t think about… until it breaks.

And when it does:

Apps can go down
Services appear unreachable
Debugging becomes tricky

Even if your backend is perfectly fine.

💡 Final Thought

DNS is not just a lookup system.
It’s a globally distributed system optimized for latency, scale, and reliability.

💬 Discussion

Have you run into DNS-related issues in production?

Cache inconsistencies?
DNS propagation delays?
Unexpected outages?

Curious to hear real-world experiences 👇

backend #dns #networking #systemdesign #performance #scalability #codewithishwar

🌐 What Happens When You Type a URL? (DNS Explained for Developers)

CodeWithIshwar — Fri, 10 Apr 2026 17:52:41 +0000

Every developer uses the internet… but very few truly understand what happens when you type:

www.google.com

Let’s break down the DNS resolution process step by step.

🔁 DNS Resolution Flow

1. Local Cache Check

Your system first checks:

Browser cache
OS cache

👉 If found → instant response (no network call)

2. DNS Resolver

If not cached, the request goes to a DNS resolver (ISP or public DNS like Google DNS).

3. Hierarchical Lookup

The resolver performs a step-by-step lookup:

Root Server → where is .com?
TLD Server → where is google.com?
Authoritative Server → returns actual IP

4. Caching (TTL)

The result is cached for future requests.

👉 This is why repeated requests are faster.

🧠 What’s the Algorithm Behind DNS?

DNS is not a single algorithm. It’s a combination of:

🌳 Tree traversal (Root → TLD → Domain)
🔁 Recursive + iterative queries
⚡ Aggressive caching
🧩 Hash-based lookups internally

⚡ Try It Yourself

Use nslookup or dig to see DNS in action:

nslookup google.com

dig google.com

🚨 Why Caching Matters

Without caching:

Every request → multiple network hops

With caching:

Near O(1) lookup

👉 That’s the difference between slow systems and internet-scale systems.

🔥 Real-World Insight

DNS is not just a lookup system.

It is designed to:

Handle billions of requests
Maintain low latency
Stay resilient during failures

💡 Final Thought

DNS is a globally distributed, cached lookup system optimized for speed and scale.

💬 Discussion

Have you ever debugged a DNS issue?

Cache inconsistency?
Wrong IP resolution?
DNS outage?

Share your experience 👇

webdev #backend #dns #systemdesign #networking #programming #devops #codewithishwar

You Don’t Need to Scale Yet (Most Engineers Get This Wrong)

CodeWithIshwar — Wed, 08 Apr 2026 17:16:53 +0000

Scaling is often treated as the ultimate goal in system design.

But here’s the truth:

Most systems don’t need scaling.
They need better thinking.

🚨 The Problem

We design systems for:

Millions of users
High availability
Distributed scale

Even when our current system:

Handles traffic comfortably
Has no real bottlenecks

So we add:

Microservices
Queues
Caching layers

And complexity increases.

🔍 What’s Actually Going Wrong?

Before scaling, most systems suffer from:

Poor queries
Weak data models
Unnecessary processing
Lack of clarity in requirements

Scaling doesn’t solve these.

It hides them.

⚡ Real Signals You Need to Scale

You should consider scaling when:

CPU usage is consistently high
Database becomes a bottleneck
Response time increases with traffic
System fails under load

And importantly:

👉 You’ve already optimized your system.

❌ The Cost of Scaling Too Early

Harder debugging
Slower development
More failure points
Increased complexity

You end up solving problems you created.

✅ A Better Way

Before scaling:

Optimize queries
Improve data modeling
Remove unnecessary work
Identify real bottlenecks

Then scale.

💣 Key Insight

You don’t scale your system.
You scale your problems.

💬 Let’s Discuss

At what point do you decide it’s time to scale your system?

You Probably Don’t Need to Scale Yet

CodeWithIshwar — Wed, 08 Apr 2026 17:15:36 +0000

Scaling is one of the most talked-about topics in system design.

But here’s the reality:

Most systems don’t need scaling.
They need better design.

🚨 The Common Trap

It’s easy to design for “future scale.”

So we add:

Microservices
Message queues
Caching layers

Even when our system has:

Low to moderate traffic
Manageable load

It feels like we’re being prepared.

But often, we’re just adding complexity.

🔍 Real Problems vs Imaginary Problems

Before scaling, most systems actually suffer from:

Poor database queries
Inefficient data models
Unnecessary processing
Lack of clear requirements

Scaling doesn’t fix these.

It hides them.

⚡ When You Actually Need to Scale

You should think about scaling when:

CPU usage stays consistently high
Database becomes a bottleneck
Response time increases with traffic
Traffic spikes cause failures

And most importantly:

👉 You’ve already optimized your system.

❌ What Happens If You Scale Too Early?

Debugging becomes harder
System complexity increases
Development slows down
Ownership becomes unclear

You end up solving problems you created.

✅ A Better Approach

Before scaling:

Optimize queries
Improve data modeling
Remove unnecessary work
Identify real bottlenecks

Then—and only then—scale.

💣 Key Insight

You don’t scale your system.
You scale your problems.

🧠 Final Thought

Simple systems scale better.

Not because they are powerful,
but because they are understood.

💬 Discussion

When do you usually decide it’s time to scale your system?

When “Healthy Systems” Fail: A Debugging Story You Don’t See in Tutorials

CodeWithIshwar — Tue, 07 Apr 2026 17:15:12 +0000

When “Healthy Systems” Fail: A Debugging Story You Don’t See in Tutorials

Everything looked normal. That was the problem.

⏰ It Started at 2:07 AM

Production issues usually come with noise.

High CPU.
Memory spikes.
Error logs everywhere.

This one didn’t.

CPU was stable.
Memory was fine.
Logs were clean.

And yet…

Users were dropping.

🤯 The Most Dangerous Kind of Failure

When systems break loudly, they’re easier to fix.

When they break silently, they’re dangerous.

Because:

👉 Your tools tell you everything is fine
👉 Your users tell you it’s not

🔍 Where We Started

We followed the standard debugging path:

Infrastructure
Database
Network
APIs

Everything checked out.

No bottlenecks. No anomalies.

🧠 The Turning Point

At some point, we realized:

This is not a system problem.

This is a thinking problem.

We changed the question:

❌ “What is broken?”
✅ “What is different?”

🔄 Looking Beyond Metrics

Instead of staring at dashboards, we started looking at:

Request patterns
User behavior
Flow-level anomalies

And that’s where things got interesting.

💡 The Root Cause

A rarely used user flow.

Almost invisible under normal conditions.

But when triggered:

👉 It created a silent loop
👉 Requests never completed
👉 No logs. No errors. No alerts

The system didn’t crash.

It just… stopped responding.

⚡ The Reality

Fixing it?

→ 5 minutes

Finding it?

→ Hours

📉 Why This Was Hard

Because we were trained to look for:

Errors
Exceptions
Resource spikes

But none of those existed.

🧠 What This Taught Me

1. “Healthy” Doesn’t Mean Working

Systems can look fine and still fail users.

2. Monitoring Has Limits

Metrics show signals — not always truth.

3. Debugging Is About Thinking

The real skill is not tools.

It’s:

Asking better questions
Challenging assumptions
Seeing patterns others miss

4. Silent Failures Are the Worst

Because they hide in plain sight.

🤖 AI Can Help… But Not Here

AI can:

Write code
Suggest fixes
Improve speed

But this kind of problem?

Requires:

💥 Context
💥 Intuition
💥 Pattern recognition

🚀 Final Thought

The hardest bugs are not the ones that crash your system.

They are the ones that quietly break it…

While everything looks fine.

💬 Let’s Discuss

Have you ever faced a situation where:

👉 Monitoring said “all good”
👉 But reality said “something’s wrong”

What did you learn from it?