“Can we just add a real-time visitor counter to the homepage? It’s just a query, right”?

Every engineer has heard some variation of this. On the surface, the logic is sound. You have data, you have a UI, and you want to connect them. In the world of business requirements, this is a solved problem. You write a line of code, and the feature exists.

But your database doesn’t care about business logic. It cares about Infrastructure Constraints.

While the request sounds like a simple query, the gap between the requirement and the execution is where the hidden costs live. You aren’t just “showing a number”; you are introducing global lock contention on a high-traffic table, triggering COUNT(*) scans on 100M rows, and potentially pinning your database CPU at 100% during peak hours.

“For every complex problem, there is a solution that is simple, neat, and wrong”. - H.L. Mencken

This is the Implementation Gap: the distance between the logical intent and the physical cost of execution.

The logic vs. the stack

We often operate in two different modes:

1. The feature mode

This is where requirements are born. The goal is to move fast, reduce uncertainty, and get feedback. Here, code is just a means to an end. If it “works” on a local dev machine with 100 rows, the requirement is considered met.

2. The system mode

This is where the stack lives. This mode is governed by the physics of computation: memory latency, network overhead, and concurrency limits. In this mode, every line of code is an allocation, a network round-trip, or a lock that must be managed.

The model

After a few years of building and breaking things, you start to develop an understanding of your stack. This isn’t about job titles; it’s about Tacit Knowledge. It’s the intuition you develop after watching a “quick fix” turn into a 2 AM outage.

You start to see the infrastructure behind the syntax. When you hear “real-time counter”, you aren’t thinking about the SQL; you’re thinking about the lock contention on the index. You aren’t being a “blocker”; you are observing the mechanical limits of your environment.

Bridging the gap: the API of options

The most expensive mistake an engineer can make is trying to explain Infrastructure Complexity to someone who is focused on Product Feedback.

If you explain “why it’s hard” in technical terms, you sound like you’re making excuses. It reminds me of the scene in The Big Bang Theory where Penny is trying to explain social conventions to Sheldon, and after listening to his pedantic reasoning, she realizes: “Now I know what I sound like to you when I say stupid stuff”.

When we lecture a product manager on database internal locks, we are Penny. We are just saying “stupid stuff” that doesn’t map to their reality. Instead, you should treat your expertise as a system interface that provides Validated Options.

Instead of a “No”, offer a path that separates the experiment from the infrastructure.

• The Request: “We need a real-time visitor counter”.
• The Feature View: “Let’s just query the visits table directly”.
• The System View: “That will kill the DB. We need a pre-aggregated counter service”.
• The Bridge: “If we want to see if users care about visitor counts, let’s hardcode a ‘5,000+ users today’ badge for 48 hours. If it moves the needle, we’ll invest the time to build the counter service properly next week”.

Engineering is the management of trade-offs between what the business wants and what the infrastructure can sustain. When a request feels like friction, it is usually just your model flagging a resource contention before it happens. Use that intuition to offer a low-fidelity path that validates the idea without pinning your database.