Good abstractions are great when you are building software.
They are much less great when you are debugging production.
The reason is simple: abstraction hides details, and debugging often depends on the details you hoped to ignore.
In small codebases, this is barely noticeable. In real systems, especially with caches, async flows, optimistic UI, and multiple state owners, it becomes a serious problem.
The core issue
The more layers you add, the easier it is for the system to become “locally correct” and “globally wrong”.
For example:
- the frontend thinks the payment succeeded,
- the backend committed the transaction,
- the event was published,
- the cache still serves the old value,
- the UI shows stale data.
Every layer is doing something reasonable.
The problem is that they are not all talking about the same version of reality.
A simple example
Imagine this flow:
- User clicks Retry payment
- Frontend updates UI optimistically
- API returns
200 OK
- Database is updated
- Event is sent to downstream systems
- Redis still serves old state
- UI refreshes from cache and shows stale data
This is the kind of bug that wastes hours.
Not because any single line of code is hard, but because the truth is spread across several places.
Example in code
Let’s say the frontend uses optimistic updates:
const onRetryPayment = async () => {
setPaymentStatus("PAID");
try {
const response = await fetch("/api/payments/retry", {
method: "POST",
});
if (!response.ok) {
throw new Error("Retry failed");
}
} catch (error) {
setPaymentStatus("FAILED");
}
};
At first glance, this looks fine.
But now imagine:
- the API succeeds,
- the DB is updated,
- an event is emitted,
- a consumer deduplicates the event incorrectly,
- Redis still contains the old value,
- the UI re-renders from stale cache.
The bug is no longer in this function.
The bug is in the propagation path.
Why abstractions make this worse
Abstractions hide the exact mechanics that matter during incidents.
They hide things like:
- who owns the state,
- when the state changes,
- whether the update is synchronous or async,
- whether caches are invalidated,
- whether retries are safe,
- whether events can arrive out of order.
That is useful in normal development.
It is terrible during debugging.
Because when something is wrong, you do not need another clean interface. You need visibility.
Typical failure patterns
These are the patterns I see most often in real systems.
1. Stale read
The data was updated, but one layer still serves an old version.
// DB updated successfully
await db.payment.update({
where: { id: paymentId },
data: { status: "PAID" },
});
// Cache not invalidated
Result:
- DB =
PAID
- cache =
PENDING
- UI =
PENDING
2. Lost update
Two writes happen close together, and one silently overwrites the other.
await updateProfile({ name: "Alex" });
await updateProfile({ name: "John" });
If the system uses last-write-wins without proper locking or versioning, the final state may not match user intent.
3. Ghost update
One layer changes, but another never receives the update.
dispatch(updateOrderStatus("PAID"));
// but query cache is never invalidated
The result is a UI that looks stuck even though the backend is correct.
4. Event reorder bug
Events arrive in a different order than they were produced.
// Event B processed before Event A
processEvent("payment_succeeded");
processEvent("payment_pending");
Now the final state may be wrong even if both handlers are valid.
The debugging trap
The trap is assuming this is a code bug.
Very often it is not.
It is a state ownership bug.
That means the real question is not:
- “Which function crashed?”
The real question is:
- “Which layer is the source of truth right now?”
If you cannot answer that clearly, debugging becomes guesswork.
A better way to think about it
Instead of thinking in terms of “where is the bug?”, think in terms of “where does state live?”
A useful checklist:
- Where is the canonical value stored?
- Which layer may cache it?
- Which layer may derive it?
- Which layer may overwrite it?
- Which layer may delay it?
- Which layer may retry it?
If the same value exists in five places, you now have five opportunities for disagreement.
Debugging strategy
When a bug crosses abstraction boundaries, I usually inspect it in this order:
Step 1: Check the source of truth
Confirm where the canonical data lives.
Step 2: Rebuild the timeline
Trace the state from user action to backend write to cache update to UI read.
Step 3: Check invalidation
If a cache exists, verify it is updated or cleared at the right moment.
Step 4: Check idempotency
If retries or events are involved, verify the operation can safely happen more than once.
Step 5: Check ordering
If events are async, verify the system does not depend on strict ordering unless it actually guarantees it.
When abstractions do help
This is not an anti-abstraction argument.
Good abstractions are still valuable when they:
- reduce search space,
- make ownership clear,
- keep state local,
- expose transitions explicitly.
For example, a small component with local state is easier to debug than three caches and two event consumers trying to keep the same value in sync.
function Counter() {
const [count, setCount] = useState(0);
return (
<button onClick={() => setCount(count + 1)}>
Count: {count}
</button>
);
}
This is easy to reason about because there is one owner of the state.
That is the difference.
What to do in real systems
If you want abstractions to stay helpful in production, make them observable.
That means:
- add logs at boundaries,
- use trace IDs,
- keep ownership explicit,
- invalidate caches intentionally,
- design retries to be safe,
- avoid hidden duplicated state.
A good abstraction should reduce complexity, not hide the mechanics that make incidents debuggable.
Final thought
The best abstractions are honest.
They do not pretend the system is simpler than it is. They make the system easier to understand without hiding where truth lives.
That is why debugging gets harder as systems grow: not because abstraction is bad, but because abstraction is often too successful at hiding the exact thing you need under pressure.
SOCIAL SHARE CARD GENERATOR