CH09-04: Backend Placement, Data Access, and Integration

Goal

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

API Management can expose and protect a contract, but it does not decide every backend responsibility. Backend placement still follows the compute, data, integration, and security decisions from Part 2.

The durable idea is:

The API gateway exposes contracts; backend placement still follows compute, data, integration, and security responsibilities.

The Short Version

An API platform usually has at least two architectural layers:

• The API boundary, where consumers call a governed contract.

• The backend layer, where services run business logic and work with data or integration systems.

The gateway should not hide weak backend design. If an order API is slow because it calls five unreliable systems synchronously, placing API Management in front of it will not magically make the workflow reliable. If a customer API uses a shared database with unclear ownership, the gateway does not fix the data boundary.

Use the same service-selection habit from earlier chapters:

Choose backend services by workload shape, data responsibility, integration pattern, security boundary, operating model, and cost.

Backend Responsibility Model

Behind API Management, a backend path often looks like this:

flowchart LR
    APIM["API Management<br/><small>Contract and policy boundary</small>"]
    API["Backend API runtime<br/><small>Business logic</small>"]
    ID["Managed identity<br/><small>Credential reduction</small>"]
    KV["Key Vault<br/><small>Secrets, keys, certificates</small>"]
    DATA["Data stores<br/><small>Azure SQL, Cosmos DB, Storage</small>"]
    BUS["Service Bus<br/><small>Durable asynchronous work</small>"]
    MON["Monitoring<br/><small>Gateway, backend, dependency signals</small>"]

    APIM --> API
    API --> ID
    ID --> KV
    API --> DATA
    API --> BUS
    APIM --> MON
    API --> MON
    DATA --> MON
    BUS --> MON

The backend API is not just a target URL. It is where business rules, data ownership, integration decisions, and failure handling live.

Choosing Backend Hosting

Several Azure services can host API backend code. The right choice depends on workload shape and operating responsibility.

Do not choose the hosting service only because the gateway can route to it. Choose it because it matches how the backend is built, scaled, deployed, secured, and operated.

Data Access Behind APIs

APIs often sit in front of important data. That makes backend data ownership one of the most important design decisions.

Azure SQL Database is often a fit for relational data, transactions, reporting-friendly structures, and systems where SQL querying and relational constraints matter. Azure Cosmos DB may fit globally distributed, low-latency, document or key-value style access patterns where partitioning, scale, and consistency choices are central. Blob Storage fits object data such as documents, images, exports, and files.

The API contract should not expose the database design directly. Consumers should call business capabilities, not table structures.

Ask these questions:

• Which backend service owns this data?

• Is the data relational, document-oriented, object-based, or event-like?

• What consistency does the API promise to consumers?

• Can the backend authorize access at the data level?

• Should the dependency be reached through private endpoints?

• How are secrets avoided or stored?

• Which logs show data access failures and suspicious activity?

Managed identities, Key Vault, private endpoints, private DNS, RBAC, database permissions, and diagnostic logs all remain relevant behind the API boundary.

When to Use Durable Integration

Not every API request should synchronously complete every downstream step.

Synchronous APIs are useful when the caller needs an immediate answer and the backend can reliably complete the work within the expected response time. For example, reading product details or validating a customer profile may be synchronous.

Durable asynchronous integration is useful when the API request starts work that may take longer, involve retries, or depend on systems that should not block the caller. Azure Service Bus is a common Azure service for reliable messaging between application components. It can hold messages until a backend worker is ready, support retry and dead-letter patterns, and decouple the API response from downstream processing.

For example, an order API might:

1. Validate the request.

2. Create an order record.

3. Publish a fulfillment message to Service Bus.

4. Return an accepted or created response.

5. Let a worker process fulfillment asynchronously.

This does not make the design simpler in every way. It introduces message contracts, idempotency, retries, monitoring, and eventual consistency. But it may be the right design when synchronous calls would make the API fragile.

Example: Order API Behind the Gateway

Imagine an order API exposed through API Management.

Consumer
  -> API Management validates caller and applies policy
  -> Order API on App Service or Container Apps
  -> Azure SQL stores order state
  -> Service Bus receives fulfillment message
  -> Fulfillment worker processes message
  -> Monitoring tracks gateway, API, database, and queue health

The gateway controls the contract boundary. The Order API owns order validation, order state, idempotency, and the decision to publish durable fulfillment work. The worker owns fulfillment processing. Azure SQL owns relational order data. Service Bus owns reliable message transfer.

That separation is what makes the architecture explainable.

Common Mistakes

• Making the gateway responsible for backend workflow.

• Calling slow or unreliable downstream systems synchronously from every API request.

• Sharing one database across unrelated API domains without ownership boundaries.

• Choosing AKS for every API because it is possible to run APIs on Kubernetes.

• Exposing database-shaped endpoints instead of business capabilities.

• Forgetting private access, managed identities, Key Vault, and backend dependency logs.

If Someone Asks You

How do backend services fit behind an Azure API platform?

A good answer is:

API Management exposes and protects the consumer contract, while backend services own business logic, data integrity, integration, and domain authorization. Backends may run on App Service, Container Apps, AKS, Functions, or other compute based on workload shape. They should access data and dependencies securely using managed identities, Key Vault where needed, private access where required, and monitoring. If work is long-running or unreliable, the API may hand durable work to Service Bus instead of doing everything synchronously.

What You Should Remember

Backend services carry business, data, and integration responsibilities behind the API contract.

Questions to Check Your Understanding

1. Why should backend placement follow workload responsibility?

2. When might Service Bus belong behind an API?

3. What security controls should backend dependencies use?

4. Why should APIs avoid exposing database structure directly?