DEV Community: Frozen Blood

The API Was “Fast” — Until One User Made It Slow for Everyone

Frozen Blood — Tue, 24 Mar 2026 16:37:08 +0000

We had an API that was consistently fast.
~80ms average response time. No complaints.

Then one day, everything slowed down.
Not crashed. Not broken. Just… slow.

And the weird part?

It was caused by one user.

The Symptom: Latency Gradually Creeping Up

At first:

p95 latency increased slightly
CPU was fine
Memory was stable
No obvious errors

Then:

Requests started taking 500ms+
Some hit 2–3 seconds
But only during certain times

It wasn’t global traffic.
It was something more subtle.

The Clue: One Endpoint, One Pattern

After digging into logs, we noticed:

Almost all slow requests hit the same endpoint
Same query pattern
Same user ID appearing frequently

That user had… a lot of data.

Way more than anyone else.

The Root Cause: “Works Fine” Query That Didn’t Scale

Here’s the query (simplified):

SQL:

SELECT *
FROM orders
WHERE user_id = $1
ORDER BY created_at DESC;

Looks harmless, right?

Except:

No pagination
No limit
That user had 120,000+ rows

Every request:

Pulled all rows
Sorted them
Serialized them into JSON
Sent them over the network

For one user.

Now imagine multiple requests hitting that at once.

Why It Slowed Down Everyone

Node.js is non-blocking… but not magic.

What actually happened:

Huge DB query time increased
Large JSON serialization blocked the event loop
Response size increased network time
Other requests waited behind it

One “heavy” request created backpressure for everything else.

The Fix (That Took 10 Minutes)

1️⃣ Add Pagination (Always)

SQL:

SELECT *
FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 50 OFFSET $2;

Or even better: cursor-based pagination.

2️⃣ Add Proper Index

CREATE INDEX idx_orders_user_created
ON orders(user_id, created_at DESC);

This alone drastically reduced query time.

3️⃣ Reduce Payload Size

Instead of SELECT *:

SELECT id, total, status, created_at
FROM orders
WHERE user_id = $1
ORDER BY created_at DESC
LIMIT 50;

Less data → faster everything.

4️⃣ Optional: Protect the API

We added a soft guard:

if (limit > 100) {
  throw new Error("Limit too high");
}

No more accidental “give me everything.”

The Lesson That Stuck With Me

The API wasn’t fast.

It was fast for the average case.

The moment one user had “edge-case data,” the system showed its real behavior.

The Dangerous Assumption

“It works fine with my test data.”

Test data is small. Clean. Predictable.

Production data is:

messy
uneven
sometimes extreme

Systems fail at the edges — not the average.

Conclusion / Key takeaway

Your backend performance isn’t defined by your average user. It’s defined by your heaviest one.

If one user can slow everyone else down, it’s not a user problem — it’s a system design problem.

What’s the most unexpected “edge case” in your data that caused real performance issues?

[Boost]

Frozen Blood — Thu, 05 Mar 2026 04:28:56 +0000

Our AWS Bill Spiked 3x Overnight — It Wasn’t Traffic, It Was One Missing Limit

Frozen Blood ・ Mar 3

#devops #aws #cloud #backend

Our AWS Bill Spiked 3x Overnight — It Wasn’t Traffic, It Was One Missing Limit

Frozen Blood — Tue, 03 Mar 2026 16:07:08 +0000

One morning I opened AWS Billing and saw something that makes every DevOps engineer uncomfortable: a sharp vertical spike.
No marketing campaign.
No traffic surge.
No new feature launch.

Our AWS cost had tripled in less than 24 hours.

Here’s what happened — and the guardrail I’ll never skip again.

The Setup: “It’s Just a Background Job”

We had a background worker running on EC2. Its job was simple:

Pull messages from SQS
Process media files
Upload results to S3
Delete the message

Standard stuff.

We had recently increased concurrency to “speed things up.”

Node.js worker (simplified):

while (true) {
  const messages = await sqs.receiveMessage({ MaxNumberOfMessages: 10 }).promise();

  await Promise.all(
    messages.map(msg => processJob(JSON.parse(msg.Body)))
  );
}

It worked great in testing.

Until production.

The Silent Problem: No Concurrency Ceiling

Under certain failure conditions:

processJob retried internally
Jobs took longer
Messages weren’t deleted fast enough
More instances scaled up

Because we had:

An Auto Scaling Group
CPU-based scaling policy
No max instance cap set properly

AWS did exactly what it was told to do:

“CPU high? Add instances.”

It added them.

And kept adding them.

The Cascade Effect

Here’s how it spiraled:

Jobs slow down → CPU increases
ASG launches more EC2 instances
More instances pull more SQS messages
Downstream dependency throttles
Retries increase
CPU spikes more
Repeat

It wasn’t traffic.

It was self-amplifying concurrency.

By the time we noticed:

EC2 count had doubled
S3 PUT requests spiked
Data transfer increased
NAT gateway costs quietly ballooned

AWS didn’t fail.
Our assumptions did.

The Fix (What I Should Have Done First)

1️⃣ Hard Cap the Auto Scaling Group

Always define a maximum instance count.

Terraform example:

resource "aws_autoscaling_group" "workers" {
  max_size         = 5
  min_size         = 1
  desired_capacity = 2
}

No infinite scaling. Ever.

2️⃣ Limit Application-Level Concurrency

Instead of unlimited Promise.all, I switched to controlled parallelism:

import pLimit from "p-limit";

const limit = pLimit(5);

await Promise.all(
  messages.map(msg =>
    limit(() => processJob(JSON.parse(msg.Body)))
  )
);

Infrastructure scaling + unlimited app concurrency = chaos.

Pick one.

3️⃣ Add Circuit Breakers

If downstream dependency fails:

Stop pulling new messages
Pause briefly
Fail fast instead of retrying blindly

Backpressure is not optional in distributed systems.

4️⃣ Billing Alerts (The Obvious One)

I added:

AWS Budget alerts at 50%, 75%, 90%
Cost anomaly detection
Slack notifications

Embarrassingly, we had none of that before.

The Lesson Most Teams Learn Once

Cloud doesn’t break loudly.

It scales quietly.

And scaling is expensive when the trigger condition is flawed.

AWS is incredibly good at doing what you configure.
It will happily automate your mistakes.

Conclusion / Key takeaway

Our AWS bill didn’t spike because of growth.
It spiked because we removed a limit and trusted scaling without boundaries.

In cloud systems, unbounded concurrency is a liability.

Have you ever had an AWS (or cloud) cost surprise? What guardrail did you add afterward?

The Codebase Isn’t Slow — Your Decisions Are Catching Up

Frozen Blood — Fri, 27 Feb 2026 16:05:10 +0000

At some point in every project, someone says it:

“The codebase is getting slow.”

Slow builds. Slow feature delivery. Slow onboarding.
But most of the time, the codebase isn’t the real problem.

It’s accumulated decisions finally demanding payment.

The Illusion of “It Works, Ship It”

Early in a project:

You skip validation because “we trust the input.”
You duplicate logic because “we’ll refactor later.”
You avoid abstraction because “it’s just one screen.”

And you’re right.

Until it isn’t.

Because code doesn’t forget shortcuts — it compounds them.

Technical Debt Isn’t About Messiness

Messy code is obvious.

The real debt hides in:

Implicit coupling
Shared mutable state
Business rules scattered across files
“Temporary” conditionals that became permanent

It looks clean on the surface.
But touching one file breaks three others.

That’s not slowness. That’s fragility.

The Telltale Signs Your Decisions Are Expiring

You’ll notice patterns like:

Adding one feature requires editing 6+ files
Tests fail for unrelated modules
Refactors feel dangerous
Junior devs avoid certain folders

That folder everyone avoids?
That’s architectural interest accumulating.

A Small Example That Grows Big

Early version:

JavaScript:

function calculatePrice(user, item) {
  if (user.isPremium) {
    return item.price * 0.8;
  }
  return item.price;
}

Six months later:

function calculatePrice(user, item) {
  if (user.isPremium && !user.isSuspended) {
    if (item.category === "digital") {
      return item.price * 0.75;
    }
    return item.price * 0.8;
  }

  if (user.coupon && !item.excludeCoupons) {
    return item.price - user.coupon.amount;
  }

  return item.price;
}

Another quarter passes…
Now tax logic is in there. Regional logic. Experimental pricing flags.

The function isn’t bad.

But the decision to centralize business logic without boundaries eventually collapses under complexity.

The Real Cost Isn’t Performance

It’s hesitation.

When engineers hesitate:

Velocity drops
Bugs increase
Refactors are avoided
Workarounds multiply

That’s when teams say:

“The codebase is heavy.”

It’s not heavy.
It’s layered.

The Fix Isn’t “Rewrite It”

Rewrites are emotional reactions.

Better moves:

Isolate unstable logic behind clear interfaces
Extract business rules into composable units
Add guardrail tests before refactoring
Reduce hidden dependencies

Architecture improves incrementally — not dramatically.

Why This Always Happens

Because optimization for:

Speed of shipping eventually conflicts with
Speed of change

The first phase rewards momentum.
The second phase demands structure.

And most teams don’t consciously transition between the two.

Conclusion / Key takeaway

When a codebase feels slow, it’s usually not because it’s big. It’s because earlier decisions are no longer aligned with current complexity.

The question isn’t:

“How do we make this faster?”

It’s:

“Which past decision is no longer serving us?”

What’s one architectural decision you made early in a project that you’d redesign today?

I Almost Ran rm -rf / on Production — And It Changed How I Deploy Forever

Frozen Blood — Wed, 11 Feb 2026 09:33:50 +0000

There’s a specific kind of silence that happens when your terminal cursor blinks… and you realize you’re connected to production.

I didn’t actually wipe the server.
But I was one Enter key away.

Here’s what happened — and the small habits I changed that probably saved me (and might save you too).

The Setup: A “Quick Fix” at 1:17 AM

Classic story:

Minor config bug
“It’ll take 2 minutes”
SSH into the server
Fix a path
Restart the service
Go to sleep

Except I had two terminals open:

One connected to staging
One connected to production

They looked almost identical.

Same prompt.
Same theme.
Same everything.

I typed:

rm -rf dist

And then I noticed the hostname.

Production.

Why This Was Worse Than It Sounds

That project didn’t just store build artifacts in dist/.
It also had runtime-generated files.

And since I was inside the app directory, not root, rm -rf dist wouldn’t nuke the whole machine — but it would absolutely break live traffic.

It would have:

Deleted compiled output
Broken running processes on restart
Forced an emergency redeploy

All because I didn’t slow down for 3 seconds.

The Real Problem Wasn’t the Command

It was this:

Production access was too easy
The environment looked too similar
Destructive commands had no friction
There were no guardrails

It wasn’t a technical issue.
It was a design flaw in my workflow.

What I Changed Immediately

1️⃣ Aggressively Different Shell Prompts

Production is now bright red in my terminal.

Using .bashrc:

export PS1="\[\e[1;31m\][PROD] \u@\h:\w$ \[\e[0m\]"

If I SSH into prod, it screams at me.

No more guessing.

2️⃣ Alias Protection for Dangerous Commands

I added interactive flags to destructive commands:

alias rm='rm -i'
alias mv='mv -i'
alias cp='cp -i'

Now I must confirm before deleting.

Is it slightly annoying?
Yes.
Is it better than downtime? Also yes.

3️⃣ Production Is Now Mostly Immutable

Instead of:

SSH → change files → restart

I moved to:

Build locally or in CI
Deploy artifact
Restart via process manager

No editing files on prod. Ever.

If I need to “fix something quickly,” I fix it in code and redeploy.

4️⃣ Reduced Direct SSH Access

Now:

Logs are centralized
Restarts are script-driven
Environment variables are managed via config

If I SSH, something is already very wrong.

The Psychological Lesson

Most production disasters don’t come from incompetence.

They come from:

Fatigue
Familiarity
Repetition
“Just this once”

The most dangerous command isn’t rm -rf.
It’s confidence.

The Quiet Truth About DevOps

We talk about:

Kubernetes
Blue-green deploys
Zero-downtime rollouts

But the simplest protection is often:

Make dangerous actions slightly harder.

Friction is underrated.

Conclusion / Key takeaway

I didn’t delete production.
But that near-miss changed how I treat access, commands, and environments forever.

The scariest production story isn’t the one where everything breaks.
It’s the one where you realize how easily it could have.

What’s the closest you’ve come to breaking production — and what guardrail did you add afterward?

The Day I Learned Node.js “Timeouts” Don’t Mean What I Thought They Meant

Frozen Blood — Tue, 10 Feb 2026 07:09:48 +0000

I used to think timeouts were simple: set a timeout, request fails after X seconds, done. Then I shipped a Node.js service that still got stuck under load even though “everything had a timeout.”

Turns out Node has multiple layers of timeouts, and if you set the wrong one (or only one), you can still end up with requests that hang, sockets that live forever, and a server that slowly stops accepting traffic.

Here’s the story — and how I fixed it.

The Symptom: “Random” Hangs Under Load

It started as a vague report:

“The API sometimes takes forever.”
“It’s not crashing, it just… stops responding.”

CPU was fine. Memory was fine. No obvious errors.

But the number of open connections kept climbing. And once it crossed a certain point, even healthy endpoints felt slow.

Classic “works until it doesn’t.”

The Mistake: I Only Set the Wrong Timeout

I had code like this:

JavaScript (Node.js):

import http from "http";

const server = http.createServer(async (req, res) => {
  // ...business logic
  res.end("ok");
});

// I thought this solved it:
server.setTimeout(10_000);

server.listen(3000);

I believed server.setTimeout() meant:

“Kill any request that takes longer than 10 seconds.”

Nope.

That timeout is mainly about idle socket activity (and behavior differs across Node versions and request patterns). If the connection is still “active” in certain ways, you can still end up with long-lived sockets.

And even worse: my outbound calls (to other services) didn’t have proper timeouts either.

The Real Root Cause: Outbound Requests Without Timeouts

We had a dependency call like:

const r = await fetch("https://some-service/api/data");
// sometimes this never returned under network weirdness

In the real world:

DNS can hang
TLS negotiation can stall
upstream can accept the connection but never respond
proxies can behave badly

If you don’t set timeouts on outbound calls, your handler can hang while the client connection stays open… and then your server slowly fills up with stuck requests.

The Fix: Put Timeouts at the Right Layers

I fixed it with a three-layer timeout strategy:

1) Request-level timeout (application logic)

Use AbortController so the operation stops.

JavaScript (Node.js 18+):

async function fetchWithTimeout(url, ms = 5000) {
  const controller = new AbortController();
  const id = setTimeout(() => controller.abort(), ms);

  try {
    const res = await fetch(url, { signal: controller.signal });
    return res;
  } finally {
    clearTimeout(id);
  }
}

Now my outbound call can’t hang forever.

2) Server headers timeout (protect against slowloris / slow clients)

These are more reliable for “client is too slow” cases.

server.headersTimeout = 12_000; // must be > requestTimeout in Node
server.requestTimeout = 10_000;

This helps when clients keep connections open and drip headers/body slowly.

3) Hard kill per request (safety net)

Even if something slips through, I wanted a final cutoff.

server.on("request", (req, res) => {
  req.setTimeout(10_000, () => {
    res.statusCode = 408;
    res.end("Request timeout");
    req.destroy();
  });
});

This makes the behavior explicit and visible.

Bonus: The One Change That Made Debugging Obvious

I added logging on aborted requests and tracked active handles:

process.on("warning", (w) => console.warn(w.name, w.message));

setInterval(() => {
  console.log("Active handles:", process._getActiveHandles().length);
}, 10_000);

(Yes, _getActiveHandles() is not “clean,” but for debugging it quickly tells you if your server is accumulating stuck sockets/timers.)

Once I saw handles steadily increasing, it confirmed the leak was connections waiting on something — not memory.

What I Learned

Node timeouts aren’t one thing. They’re:

Socket / HTTP server protection
Application request timeboxing
Outbound client timeout enforcement

If you only set one, you’ll still get weird hangs in production.

Conclusion / Key takeaway

If your Node service “hangs” under load, assume it’s not mysterious. It’s usually requests waiting forever because timeouts weren’t enforced at the right layer.

Have you ever shipped a service that didn’t crash — it just slowly stopped responding? What did it end up being?

Your Web App’s Data Can Disappear — Even If the User Never Cleared It

Frozen Blood — Mon, 09 Feb 2026 13:50:07 +0000

Here’s something many developers don’t realize until it hurts: the browser is allowed to delete your app’s stored data at any time — even if the user never clicked “Clear cache.”

LocalStorage. IndexedDB. Cache Storage.
None of them are guaranteed.

Let’s talk about why this happens, when it happens, and how to design around it.

The Browser Does Not Promise to Keep Your Data

Web storage APIs feel persistent, but they’re actually best-effort.

Browsers enforce:

Storage quotas
Eviction policies
Priority rules based on usage patterns

When space is needed, something has to go — and it might be your app.

The Silent Killer: Storage Eviction

Browsers may delete site data when:

Disk space is low
The site hasn’t been used recently
The user is in private / low-storage mode
The browser decides your data is “less important”

No warning.
No exception.
Just… gone.

Your app reloads like it’s the first visit.

“But I’m Using IndexedDB, Not LocalStorage”

Good instinct — but still not safe.

Approximate priority (simplified):

User-engaged sites (frequently visited, interacted with)
Persistent storage (explicitly requested)
Everything else

If your app:

Is rarely opened
Lives behind a login
Stores large blobs (videos, offline data)

…it’s a candidate for eviction.

The One API Most Devs Don’t Use (But Should)

There’s a browser API called Persistent Storage.

JavaScript:

if (navigator.storage && navigator.storage.persist) {
  const isPersisted = await navigator.storage.persist();
  console.log("Persistent storage granted:", isPersisted);
}

If granted:

Your data is much less likely to be evicted
The browser treats it like important app data

Most apps never request this — and many devs don’t know it exists.

How Browsers Decide Who Loses Data

It’s not random. Browsers look at:

How often the user visits the site
Whether the site is installed (PWA)
User interaction signals
Storage pressure on the device

That’s why:

Offline-first apps survive longer
Background tools disappear faster
“Internal dashboards” get wiped unexpectedly

Real-World Failure Mode

This usually shows up as:

“Some users got logged out”
“Drafts randomly disappeared”
“Offline mode stopped working”
“It only happens on mobile”

And it’s brutal to reproduce.

Practical Defensive Strategies

Treat browser storage as a cache, not a database
Sync critical data to a backend
Request persistent storage for offline apps
Detect missing state and recover gracefully
Never assume stored data will exist tomorrow

If losing the data breaks your app, you designed it too optimistically.

Conclusion / Key takeaway

Browser storage feels permanent — but it isn’t. Once you accept that, you start building web apps that are more resilient, predictable, and user-friendly.

Discussion question:
Have you ever debugged “random data loss” in a web app — and later realized the browser was the culprit?

If you want tomorrow’s post to be AI, frontend-specific, or pure dev horror stories, tell me and I’ll tune it.

Global AI Cooperation Moves Forward

Frozen Blood — Sun, 08 Feb 2026 17:07:39 +0000

While AI headlines often focus on new models, a quieter shift is happening in the background: countries are starting to cooperate on AI development instead of racing in isolation. Over the past few weeks, multiple bilateral and regional agreements have signaled that AI is now a matter of international coordination — not just competition.

What’s Actually Happening

Governments are increasingly signing AI cooperation agreements that focus on:

Joint research and knowledge sharing
Standards for responsible AI use
Talent exchange and education
Shared approaches to safety and ethics

These deals don’t announce new products. They set the rules for how AI will be built, shared, and governed over the next decade.

Why This Is a Big Deal (Even If It Sounds Boring)

AI has moved into the same category as:

Cybersecurity
Energy infrastructure
Telecommunications

Once technologies reach that level, countries stop treating them as “just software” and start treating them as strategic infrastructure.

That’s what these agreements represent: AI is no longer experimental — it’s geopolitical.

From Competition to Coordination

For years, the narrative was simple: whoever builds the best AI wins.
Reality is proving more complex.

Uncoordinated AI development creates problems:

Incompatible regulations
Conflicting safety standards
Data transfer restrictions
Fragmented research efforts

Cooperation helps reduce friction — especially for cross-border companies and global platforms.

What This Means for Developers

You may not feel this immediately, but the effects will surface in real workflows:

Standardized AI disclosures across regions
Stricter requirements for AI auditability
Clearer boundaries on data usage and model training
More documentation around AI-powered features

In short: less “move fast and ship AI,” more “prove how and why this AI behaves.”

A Subtle Shift in Responsibility

As AI becomes internationally regulated, responsibility shifts downward:

From governments → companies
From companies → engineering teams

Developers won’t just write AI-powered features — they’ll help define:

What’s allowed
What’s traceable
What’s explainable

This mirrors what happened with privacy laws years ago, except AI reaches deeper into system behavior.

Why This Trend Will Continue

Global AI cooperation is still early and imperfect, but it’s accelerating because:

AI impacts elections, security, and economies
Failures cross borders instantly
No single country fully controls the ecosystem

The direction is clear: shared rules before shared disasters.

Conclusion / Key takeaway

AI progress is no longer just about smarter models — it’s about how nations agree to use them. As cooperation grows, developers will increasingly build AI features inside legal, ethical, and technical guardrails shaped far beyond their codebase.

Every Production Bug Is a Story — Most Teams Just Don’t Read It

Frozen Blood — Sat, 07 Feb 2026 11:01:34 +0000

Production bugs aren’t random. They don’t “just happen.” Every incident is the final chapter of a story your system has been telling for weeks — sometimes months — before it breaks.

Most teams only start listening when users start screaming.

Production Bugs Are Rarely About the Line That Crashed

When something fails in prod, the instinct is to ask:

“Which line caused this?”

That’s almost never the right question.

The better ones:

Why was this state possible?
Why wasn’t this path visible earlier?
Why did the system allow this combination of inputs?

The crashing line is just where the story ends — not where it starts.

The Warning Signs Are Usually Boring

Before most incidents, you’ll find:

Logs that were “a bit noisy”
Metrics that slowly drifted
Edge cases dismissed as “unlikely”
TODOs that said “handle later”

Nothing dramatic. Nothing urgent.

That’s why they’re ignored.

Teams don’t miss red flags — they miss gray ones.

Debugging in Prod Is Really Archaeology

Real-world debugging looks less like problem-solving and more like excavation:

Old assumptions buried in comments
Workarounds added under pressure
Configs changed by someone who’s no longer on the team
Code paths nobody remembers approving

By the time you’re debugging prod, you’re reconstructing decisions, not just logic.

Why “Works Fine in Staging” Is Meaningless

Production is where:

Real traffic shapes appear
Data is messy instead of ideal
Latency, retries, and partial failures exist
Users behave creatively

Staging proves correctness.
Production reveals behavior.

If your system only survives because traffic is polite, it’s already broken.

The Teams That Debug Less Aren’t Smarter

They just design differently.

Patterns you’ll see:

Clear ownership of data flows
Fewer “magic” side effects
Boring, explicit state transitions
Logs written for humans, not machines

They assume things will go wrong — and plan for reading the story later.

A Simple Habit That Changes Everything

After every incident, ask one question:

“What did the system know before users did?”

If the answer is “nothing,” you didn’t have a bug — you had silence.

Logs, metrics, and alerts aren’t for dashboards.
They’re for future you, under pressure.

Conclusion / Key takeaway

Production bugs aren’t surprises. They’re delayed conversations. The teams that suffer less aren’t faster at fixing crashes — they’re better at listening before the crash happens.

Discussion question:
What’s the earliest signal you’ve learned to trust before a production issue blows up?

Nvidia’s Next-Gen Gaming Chip Delay — What It Actually Means for Developers

Frozen Blood — Fri, 06 Feb 2026 06:33:02 +0000

If you were hoping for a clean GPU upgrade cycle in 2026… yeah, about that.

:contentReference[oaicite:0]{index=0} is reportedly delaying its next-generation gaming GPU, and the reason isn’t poor yields or bad architecture — it’s memory supply pressure caused by AI. And that detail matters a lot more than it sounds.

::contentReference[oaicite:1]{index=1}

What’s being delayed (and why)

According to recent industry reports, Nvidia’s upcoming consumer gaming GPU lineup is slipping because:

High-bandwidth memory (HBM) and advanced GDDR supply is tight
AI accelerators and data-center GPUs are getting absolute priority
Cloud providers are buying memory at volumes that gaming GPUs can’t compete with

In short:

AI GPUs are eating the memory market alive.

When Nvidia has to choose between:

Shipping a gaming GPU, or
Shipping a data-center card that sells for 10×–20× more

…that’s not a hard decision.

Why AI workloads are breaking the GPU supply chain

Modern AI training and inference don’t just need compute — they need massive memory bandwidth.

Think:

HBM3 / HBM3E
Ultra-fast GDDR variants
Huge, stable memory stacks per card

Those same memory fabs also serve:

Gaming GPUs
Consoles
High-end laptops

So when hyperscalers place giant orders, everyone else waits.

This is no longer a “temporary shortage” problem — it’s a structural shift in GPU economics.

What this means for developers (not just gamers)

This delay affects more than FPS counters.

🎮 Game & graphics devs

Slower adoption of new GPU features
Longer life cycles for existing architectures
More pressure to optimize for older cards

🧠 AI & ML engineers

Reinforces Nvidia’s dominance in data centers
Confirms that consumer GPUs are now second-class citizens
Expect cloud GPU prices to stay high

🧱 Backend & infra devs

On-prem GPU builds get more expensive
Planning capacity upgrades becomes harder
Cloud dependency increases (whether you like it or not)

If you’re building anything GPU-heavy in 2026, availability is now a first-class architectural concern.

The bigger signal Nvidia is sending

This delay quietly confirms something many devs already suspected:

Nvidia is an AI infrastructure company first. Gaming is optional.

Gaming GPUs still matter for branding and ecosystem lock-in — but:

Revenue growth
R&D focus
Supply allocation

…are all clearly pointed at AI.

That doesn’t mean gaming is “dead.”

It means gaming hardware is no longer the priority customer.

Should you care right now?

If you:

Ship games
Build GPU-accelerated tools
Run inference locally
Plan workstation upgrades

Then yes — this affects your roadmap.

If not, this is still a warning sign:
AI demand is now powerful enough to reshape entire hardware markets.

Takeaway

Nvidia’s chip delay isn’t a logistics hiccup — it’s a signal.

AI workloads are rewriting:

GPU availability
Memory economics
Hardware planning timelines

And for developers, that means optimize smarter, plan longer, and assume scarcity is the new normal.

Discussion:

Are you already feeling GPU shortages in your dev workflow — or are you fully cloud-based now?

Indexes Aren’t Magic — How Databases Really Use Them

Frozen Blood — Fri, 06 Feb 2026 06:06:57 +0000

Indexes are one of those things every developer knows they should use — but fewer developers truly understand how databases use them and why they sometimes don’t work the way you expect.

Ever added an index, shipped it to production, and saw… absolutely no performance improvement? Yeah. Let’s talk about why that happens and how to think about indexes like a database engine does.

1. What an Index Actually Is (Mentally, Not Academically)

At a high level, most indexes are sorted data structures (often B-trees) that let the database avoid scanning the entire table.

Instead of this:

“Check every row to find matches”

The DB can do this:

“Jump directly to the matching range”

Sounds great. But here’s the catch:
Indexes are only useful if the query can actually use that ordering.

2. Why `SELECT *` Can Break Index Usage

This surprises a lot of people.

SELECT * FROM users WHERE email = 'test@example.com';

Even if email is indexed, the database may still:

Use the index to find the row
Jump back to the table to fetch all columns

That second step is called a heap lookup, and it’s expensive.

Why this matters

If your query:

Returns many rows
Or fetches many columns

…the cost of table lookups can dominate.

Better approach

SELECT id, email FROM users WHERE email = 'test@example.com';

Smaller result set = fewer reads = faster query.

3. Index Order Matters More Than You Think

Consider this index:

CREATE INDEX idx_orders_user_date ON orders (user_id, created_at);

This index is great for:

WHERE user_id = 42
AND created_at >= '2025-01-01';

But not great for:

WHERE created_at >= '2025-01-01';

Why?

Indexes are sorted left to right.

The database can only efficiently use the index starting from the first column (user_id). Skip it, and the index becomes mostly useless.

Rule of thumb

Put:

Highly selective columns first
Frequently filtered columns before sorting columns

4. Functions in WHERE Clauses Kill Indexes

This is a classic footgun.

-- ❌ Index will not be used
WHERE DATE(created_at) = '2025-02-01';

Even if created_at is indexed, the database must:

Apply the function to every row
Then compare results

Fix it by flipping the logic

-- ✅ Index-friendly
WHERE created_at >= '2025-02-01'
AND created_at < '2025-02-02';

Same result. Completely different performance.

5. Low-Cardinality Indexes Often Don’t Help

Indexing a column with very few unique values is usually pointless.

Examples:

is_active
status with 3 values
deleted = false

Why?

The DB still has to scan a large portion of the table
The index doesn’t reduce the search space much

When it can make sense

Combined with other columns
On very large tables
With partial indexes

CREATE INDEX idx_active_users
ON users (id)
WHERE is_active = true;

Now that index earns its keep.

6. Indexes Speed Reads — and Slow Writes

Every index must be updated on:

INSERT
UPDATE
DELETE

Too many indexes can:

Slow down writes
Increase lock contention
Bloat memory and disk usage

The mistake

“Query is slow? Add an index.”

The better question

“Is this query hot and unavoidable?”

Indexes are trade-offs, not free upgrades.

7. Execution Plans Are Your Best Friend

If you’re not using EXPLAIN, you’re guessing.

EXPLAIN ANALYZE
SELECT id FROM users WHERE email = 'test@example.com';

This tells you:

Was the index used?
How many rows were scanned?
Where the time actually went?

Reality check

If the planner chooses a sequential scan, it’s usually for a reason.
Your job is to understand why, not to fight it blindly.

8. Covering Indexes: The Secret Weapon

A covering index includes all columns needed by the query.

CREATE INDEX idx_users_email_id
ON users (email, id);

Now this query:

SELECT id FROM users WHERE email = 'test@example.com';

Can be answered entirely from the index — no table lookup at all.

This is one of the biggest performance wins you can get for read-heavy workloads.

Key Takeaway

Indexes don’t make queries fast by default.
They make specific access patterns fast.

To use them well, you need to think like the database:

How is the data sorted?
How many rows are touched?
Are we forcing extra work?
Is the index actually selective?

The best-performing systems don’t have the most indexes — they have the right ones.

Discussion

What’s the most misleading index you’ve ever added — the one you were sure would help, but didn’t move the needle at all?

The Real Cost of Misusing React Hooks (and How to Fix It)

Frozen Blood — Thu, 05 Feb 2026 07:23:29 +0000

React Hooks feel magical at first. A few useStates, a useEffect, maybe a useMemo, and suddenly your component is alive. But as apps grow, small hook mistakes quietly turn into performance bugs, stale state, and impossible-to-debug behavior.

If you’ve ever said “Why is this effect running again?” or “Why does this value feel one render behind?”, this post is for you.

Let’s walk through the most common Hook mistakes I see in production React apps—and how experienced teams avoid them.

1. Treating `useEffect` Like a Lifecycle Dumping Ground

This is the classic one.

useEffect(() => {
  fetchUser();
  trackAnalytics();
  setIsReady(true);
}, []);

At first glance, this feels fine. But what’s actually happening?

You’ve mixed:

Data fetching
Side effects
State transitions

…into one untestable blob.

Why this bites later

Dependencies become unclear
Refactors accidentally break behavior
Effects grow instead of being replaced

The fix: one effect, one responsibility

useEffect(() => {
  fetchUser();
}, []);

useEffect(() => {
  trackAnalytics();
}, []);

useEffect(() => {
  setIsReady(true);
}, []);

It feels verbose—but clarity beats cleverness every time.

2. Ignoring the Dependency Array (or Fighting It)

If you’ve ever done this, no judgment:

// eslint-disable-next-line react-hooks/exhaustive-deps
useEffect(() => {
  doSomething(value);
}, []);

You’re telling React: “I know better.”
Most of the time… you don’t 😄

What actually goes wrong

Effects read stale values
Bugs appear only after re-renders
Logic breaks when props change

The fix: embrace dependencies

useEffect(() => {
  doSomething(value);
}, [value]);

If adding a dependency causes infinite loops, that’s a design smell, not a React problem.

3. Overusing `useMemo` and `useCallback`

Hooks for performance feel responsible. Until they’re everywhere.

const computedValue = useMemo(() => {
  return expensiveCalculation(data);
}, [data]);

The truth

useMemo is a cache, not a guarantee
It adds complexity and memory overhead
Most computations don’t need it

When you actually need it

Use useMemo or useCallback only if:

The calculation is expensive
The component re-renders often
You’ve measured a problem

Otherwise, let React re-run the function. It’s fast.

4. Storing Derived State in `useState`

This one causes subtle bugs.

const [fullName, setFullName] = useState('');

useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);

Now you have:

Source state
Derived state
Synchronization logic

All for something React can compute instantly.

The fix: derive during render

const fullName = `${firstName} ${lastName}`;

If state can be calculated from props or other state, don’t store it.

5. Mutating State Objects Accidentally

React state must be immutable. But it’s easy to forget.

// ❌ Mutates existing object
user.profile.name = 'New Name';
setUser(user);

This may not re-render at all.

The fix: always create new references

setUser(prev => ({
  ...prev,
  profile: {
    ...prev.profile,
    name: 'New Name',
  },
}));

React compares references.
If the reference doesn’t change, neither does the UI.

6. Putting Too Much Logic Inside Components

Hooks don’t mean “everything goes in the component.”

function Dashboard() {
  const data = useData();
  const filtered = data.filter(...);
  const sorted = filtered.sort(...);
  const grouped = groupBy(sorted);

  return <UI grouped={grouped} />;
}

This gets ugly fast.

The fix: extract custom hooks

function useDashboardData() {
  const data = useData();
  return useMemo(() => {
    return groupBy(sort(filter(data)));
  }, [data]);
}

Your component becomes:

Smaller
Easier to test
Easier to reuse

Hooks are abstractions, not decorations.

7. Forgetting That Hooks Run on Every Render

Hooks are not events. They are part of rendering.

const value = useExpensiveThing();

This runs every render unless you control it.

Mental model that helps

Rendering should be pure
Effects handle side effects
Memoization is an optimization, not a default

If a hook does too much work, it’s probably doing the wrong job.

Key Takeaway

React Hooks are powerful—but only if you respect their model:

Effects are for side effects, not logic dumps
Dependencies are your friend
Derived state should stay derived
Performance hooks are tools, not habits
Clean abstractions beat clever tricks

Most “weird React bugs” aren’t React bugs at all.
They’re mental model mismatches.

Discussion

What’s the most confusing Hook bug you’ve ever debugged—and what was the actual root cause once you figured it out?