If Not the Gateway, Then Where?
API Thinking, Data Interface Quadrants, and the role of capability literacy
After the last post, Allan Knabe asked a question that goes straight to the point:
“Any particular tools you’d recommend alongside the gateway to handle this business logic?”
It is the right question because it moves the conversation from what not to do in the gateway to how to decide where logic should live instead.
From tools to intent
This is where API Thinking becomes essential. It starts with intent rather than technology. Every interface exists to expose a capability, connect data, or deliver an experience. Once we understand that intent, tool choices and placement follow naturally. API Thinking begins with a few simple questions:
Who consumes this interface?
What value does it create?
Which boundary does it cross—business, data, or policy?
Without those answers, teams make placement decisions out of convenience instead of design.
The Data Interface Quadrants as a map
The Data Interface Quadrants (DIQs) give structure to that intent. They describe where an interface sits between data ownership and data purpose:
Raw Data (Internal) – close to the source, minimal logic
Aggregated or Transformed Data (Internal) – enriched inside the domain
External and Reusable Data – standardised and governed for reuse
Product-Specific Interfaces – designed for a concrete consumer or use case
Each quadrant comes with different responsibilities. Logic that defines meaning or context belongs near the data (Quadrants 1–2). Logic that defines policy or exposure belongs in governance layers (Quadrant 3). Logic that defines experience belongs in the product space (Quadrant 4). The gateway plays its natural role in Quadrant 3, where governance and exposure matter, but the logic in the other quadrants should stay within the domains and products that own it.
Capabilities as the Missing Link
Kin Lane’s recent piece What Is a Capability adds another dimension to this discussion. He describes capabilities as business aligned functions that connect purpose with implementation. A capability, in his view, is not just an API or endpoint. It is a unit of business meaning that is clearly named, bounded, discoverable, and governed.
This framing helps clarify what belongs where. If a piece of logic can be described as a reusable, composable, and discoverable function that carries business semantics and metadata, then it deserves to exist as a capability, not as code hidden inside a gateway plugin. Capabilities live within domains, not on the edge. The gateway’s job is to enforce access to them, not to become one of them.
Kin’s thinking also reinforces the connection between API Thinking and capability literacy. API Thinking ensures that we start from intent and interaction. Capability literacy ensures that we can model and govern what that intent becomes once it materialises as interfaces.
Making placement decisions
A few examples illustrate how this helps in practice:
Composition and orchestration
When combining or aggregating data for a specific experience, you are in Quadrant 4. Use a Backend-for-Frontend or a dedicated composition service rather than embedding that logic at the edge.
Policy and consent
Cross-cutting enforcement belongs in Quadrant 3. Gateways and policy engines such as OPA or Styra fit this purpose.
Domain rules and enrichment
If the goal is to apply pricing, eligibility, or scoring logic, that sits in Quadrant 2. Domain services or workflow tools should own it close to the data.
This perspective turns placement into a capability question.
Who owns the rule, who changes it, and how reusable is it across domains?
Pragmatism with awareness
Shortcuts will always exist, and that is fine. What matters is awareness. If you know which boundary you are crossing and have a plan to move logic later, you are making a deliberate trade-off, not an accidental one. Architecture does not need purity; it needs consciousness.
From Pattern Literacy to Capability Literacy
Understanding architectural patterns is important, but it is only the first layer.
Pattern literacy helps us reason about structure. Capability literacy helps us reason about value.
Capability literacy means being able to describe what a system does in terms of business intent. It is the ability to name, govern, and evolve those functions as reusable and observable capabilities. It connects business architecture and API design and helps organisations see APIs not as isolated endpoints but as expressions of capability.
When teams develop both kinds of literacy, the question of where logic belongs stops being technical. It becomes an act of intent, ownership, and design.
Closing thought
The next frontier of API architecture is not another feature inside the gateway. It is the ability to think and talk about capabilities clearly.
When we align API Thinking, Data Interface Quadrants, and capability literacy, we gain a common language for deciding what belongs where and for keeping gateways as what they were always meant to be: places of governance and trust, not containers for business logic.