Backend Placement, Data Access, and Integration

Goal

The previous sections focused on the API contract and boundary controls. This section moves behind that boundary, where backend services run business behavior, access data, and coordinate work with other systems.

An API gateway can expose and protect a contract. It does not decide every backend responsibility. Backend placement still follows runtime shape, data ownership, integration style, security boundary, team ownership, and operating model.

The durable idea is:

An API boundary should expose capability while keeping backend ownership and integration behavior visible.

The Short Version

An API platform usually has at least two layers:

• the API boundary, where consumers call governed contracts;

• the backend layer, where services own business behavior, data, and integration.

The boundary should hide unnecessary implementation detail from consumers. It should not hide ownership or failure behavior from designers and operators.

Backend Responsibility Model

API contract
  -> Backend capability
  -> Data dependency
  -> Integration flow
  -> Operating signals

This model keeps the backend visible as a responsible component, not just a target URL.

Backend services own:

• business rules;

• data integrity;

• domain authorization;

• idempotency and consistency;

• data access;

• integration with other systems;

• dependency failure handling;

• backend telemetry.

The API contract should not force consumers to know those implementation details, but the architecture should still show them.

Choosing Backend Placement

Backend placement depends on workload shape.

Do not choose the backend runtime only because the gateway can route to it. Choose it because it matches how the backend is built, scaled, deployed, secured, observed, and owned.

Data Access Behind APIs

APIs often guard important data. That makes data ownership central.

Ask:

• Which backend owns this data?

• Is the API exposing a business capability or leaking database shape?

• What consistency does the API promise?

• Can the backend authorize access at the data level?

• Should dependencies be reached through private networking?

• How are secrets avoided or stored?

• Which logs show access failures, denied access, latency, and suspicious patterns?

The API contract should not expose internal table structures, private schema decisions, or data-store quirks. Consumers should call capabilities such as creating an order, reading shipment status, or updating a seller listing.

Synchronous and Asynchronous Work

Some API calls should complete synchronously. Others should accept work and continue through a durable integration flow.

Synchronous calls fit when the caller needs the answer now and the backend can complete within the expected response time. Product lookup, cart validation, or order-status read may be synchronous.

Asynchronous flows fit when work is long-running, retry-heavy, dependent on other systems, or not required before the caller receives a useful response. Fulfillment, notification, reconciliation, fraud review, and back-office updates often fit this shape.

The API contract should make this clear. If work is accepted but not complete, the consumer needs a status model, polling endpoint, webhook, event, or other follow-up contract.

Example: Checkout API

A checkout API might follow this path:

Checkout request
  -> API boundary validates caller and applies policy
  -> Checkout backend validates cart and payment intent
  -> Order record is created
  -> Fulfillment message is published
  -> API returns created or accepted response
  -> Worker processes fulfillment and notification later

The gateway is not responsible for fulfillment workflow. The Checkout backend owns order creation, idempotency, and the decision to publish durable work. The fulfillment worker owns later processing. The data store owns order state. The messaging layer owns reliable handoff.

This design needs message contracts, retries, dead-letter handling, status visibility, and monitoring. It is worth the extra design work when synchronous calls would make checkout fragile.

Backend-for-Frontend, Domain APIs, and Internal APIs

Not every API has the same shape.

A backend-for-frontend, often called a BFF, may tailor an API for a specific experience such as mobile or web. A domain API exposes a business capability owned by a domain team. An internal API may be used by trusted services or operations tools. A partner API may expose a narrower, more stable contract to outside organizations.

These shapes can coexist. The important habit is to name the contract and owner instead of letting every route look like a generic backend endpoint.

Common Mistakes

• Letting API consumers depend on backend implementation details.

• Calling many downstream systems synchronously because it is simple to code.

• Hiding data ownership behind one shared database.

• Treating integration failure as an API gateway problem only.

• Choosing backend hosting without considering deployment, scaling, data access, and ownership.

• Making asynchronous work invisible to consumers and operators.

If Someone Asks You

What should be visible behind an API boundary?

A good answer is:

The consumer should see a stable capability contract, but the architecture should still show backend ownership, runtime placement, data dependencies, integration flows, failure behavior, and operating signals. APIs hide unnecessary implementation detail from consumers; they should not hide responsibility from the teams operating the platform.

What to Remember

APIs hide unnecessary implementation detail, not ownership or failure behavior.

Questions to Check Your Understanding

1. How should backend placement follow API responsibility?

2. Why can synchronous backend calls make APIs fragile?

3. What integration behavior should remain visible in the design?

4. How does an asynchronous API contract differ from a synchronous one?