We built a small calculator that shows how much inventory drift actually costs

Josef Smetanka — Wed, 04 Feb 2026 12:56:09 +0000

Most ecommerce sellers obsess over traffic metrics: sessions, CAC, ROAS.

But there’s a quieter line item almost nobody tracks:

How much money leaks when inventory and prices drift out of sync across channels.

Not the big obvious disasters. The small stuff that happens every week:

Oversells on the last unit
Refunds or cancellations because stock was wrong
Support time explaining “sorry, we can’t fulfill this”
Price mismatches across marketplaces and your store
“Sync says OK” but the numbers are still off

Each one feels minor. Together they compound.

So we built a small calculator that estimates the monthly cost of drift based on order volume and typical incident patterns. t’s not accounting-precise. It’s a visibility model. The assumptions are explicit so you can sanity-check them against your setup (refund rate, handling cost, future impact).

→ https://gnizdo.space/oversell-cost-calculator/ (models refunds + support handling + downstream revenue impact, assumptions included)

If you’ve worked with multi-channel systems, marketplaces, or sync pipelines, I’m curious:

What’s the most common drift failure mode you’ve seen in practice?
Does this kind of cost model miss anything important in real-world setups?

Why your system can be 100% up and still completely broken

Josef Smetanka — Sun, 01 Feb 2026 12:11:22 +0000

Your monitoring is green.
99.99% uptime.
Health checks passing.
No alerts.

Then support starts forwarding screenshots from users:

“I paid, but my order says cancelled.”
“The price changed after checkout.”
“It said in stock. Then refund.”

Welcome to a harsh truth engineers eventually learn:

Uptime measures server liveness.
Users care about state correctness.

And those are very different things.

The illusion of “up”

Most systems monitor process health:

HTTP 200 OK

But a distributed system can respond perfectly while being completely wrong.

Examples:

API returns 200 with stale data
Writes succeed but never reach downstream systems
Auth works, but data permissions are wrong
Checkout returns success, but payment never captured
Stock shows available, but orders already consumed it elsewhere

The system is alive.
The truth inside it is dead.

The real failure class: state drift

Most “it's up but broken” incidents are not crashes.
They’re state divergence problems.

Systems look healthy because:

CPU OK
DB reachable
Services responding

But internally:

caches out of sync
queues lagging
partial writes
retries overwriting newer state
external APIs delayed
eventual consistency biting you

Your monitoring says “system operational”.
Reality says “state is no longer trustworthy.”

That’s not downtime.
That’s silent correctness failure — much worse.

Why uptime is the wrong mental model

Uptime answers:

“Is the machine alive?”

Users ask:

“Did the system do the correct thing?”

Those are different layers:

Layer	What uptime measures	What users experience
Infra	Processes running	Irrelevant
Network	Requests succeed	Still irrelevant
App	Endpoint returns	Still not enough
State	Correct data & side-effects	This is what matters

Most outages today are not infrastructure failures.
They are correctness failures in distributed state.

What you should actually measure

1. Correctness SLIs

Not just response success — result validity.

Did the order actually get created?
Did payment get captured?
Did inventory decrement once, not twice?
Is user data consistent across services?

If the side-effect didn’t happen, the request was a failure — even if it returned 200.

2. End-to-end invariants

Every system has truths that must always hold:

Stock never negative
Order cannot be paid twice
One user = one identity
Total debits = total credits

These invariants breaking is worse than downtime.

3. User-journey success rate

Not “endpoint success”.
Journey success:

Login → Browse → Add to cart → Pay → Order confirmed

If this drops from 98% to 85%, you're broken.
Even if uptime is 100%.

4. Lag and staleness metrics

Distributed systems rot from delay:

queue depth
replication lag
cache age
sync delay between services

Lag is future inconsistency waiting to explode.

The mindset shift

Stop asking:

“Is the system up?”

Start asking:

“Is the system still telling the truth?”

Because modern outages look like this:

No errors
No crashes
No alerts

Just:

refunds
data mismatches
user confusion
support chaos

The worst failures are quiet.

The bottom line

A system that responds but lies is worse than a system that’s down.

Downtime is visible.
Incorrect state is invisible — until money, trust, or data integrity is gone.

Uptime is liveness.
Users care about correctness.

Those are not the same metric.

What’s the worst “everything green, everything wrong” incident you’ve seen?

DEV Community: Josef Smetanka