Cost-Bearing Abstraction

Every abstraction over a resource with variable cost leaks the cost. A query builder hides the join plan; a serverless platform hides the machine; an inference API hides the GPU. The leak is not a defect to engineer away — it is a property of the abstraction — and the design question is where to put the leak so that it is survivable.

The principle: an abstraction that hides a resource must expose a budget.

Why it matters

Without a budget, the most expressive feature becomes the largest availability risk, and it will be triggered by an ordinary user doing something reasonable rather than by an attacker. The failure is not malicious and therefore not caught by security controls; it looks like a feature working as designed.

Implementation patterns

Three places the leak can surface, and mature platforms use all three:

• At authoring time — depth limits, complexity scoring computed before execution, allow-lists of permitted operations. The only layer that prevents rather than mitigates, and the most restrictive for users.
• At execution time — statement timeouts, row limits, per-tenant connection caps, memory ceilings. Necessary regardless, because prevention is never complete. This is the backstop, not the control.
• At the economic layer — per-query or per-request cost attribution, so an expensive pattern appears on a bill or a dashboard rather than as an outage. Added last, and the one that actually changes behaviour.

Also: escape hatches are a requirement, not an admission of defeat. Raw queries, custom resolvers and materialised views exist because the customer whose usage justifies the platform is the customer most likely to hit its generated-query ceiling.

Industry example

A metadata-driven API layer such as Hasura generates database queries from a declarative request. A deeply nested query can produce a join that saturates the customer's database, and the abstraction hides exactly the signal that would have warned them. The same shape appears in an inference platform where a long prompt costs a hundred times a short one, in a GPU platform where one large job starves thousands of small ones, and in an observability platform where one high-cardinality dimension multiplies index cost.

The pattern generalises: expressiveness plus a shared finite resource equals an admission-control problem.

Failure scenarios

• One tenant's expensive query exhausting a shared connection pool, which turns a per-customer problem into a platform outage.
• Timeouts as the only control, so the resource is consumed for the full timeout duration before being killed — the work is wasted and the contention is real.
• Cost invisible until the invoice, so nothing corrects the behaviour for a month.
• Limits set for the median user, which block the largest customer and are then removed for them individually, quietly deleting the control for the accounts that most need it.

Trade-offs

Every budget mechanism costs expressiveness, which is the product's value proposition. Allow-listing operations is the strongest control and the most hostile to the developer experience that sold the platform.

The usable compromise is tiered: permissive defaults with execution-time backstops and cost attribution for everyone, plus stricter authoring-time controls available to customers who want to protect themselves. That puts the restriction where its cost is chosen rather than imposed.

Interview question

"Your product's selling point is that developers can express any query they like. A customer just took down their own database with one request. What do you change, and what do you refuse to change because it would destroy the product?"