Cloud Computing Architecture Guide

API Boundaries, Application Runtimes, and Data Access

Goal

Design the application interior by separating contracts, execution, identity, and state without assuming that every boundary must become a microservice.

The Short Version

An API boundary defines what callers may request and what the system promises in return. A runtime boundary defines what is deployed, scaled, isolated, and operated together. A data boundary defines who owns authoritative state and how it changes. These boundaries can align, but they do not have to.

A gateway may expose one customer API backed by a modular monolith and a background worker. Two APIs may share a runtime because their release cadence and ownership are the same. One service may use several state stores because transactions, search, and caching have different jobs. Good boundaries follow reasons for independent change, failure, scale, security, or ownership.

From Contract to State

Client contract
      |
      v
API entry and policy
      |
      +----> application runtime ----> authoritative order data
      |              |                         ^
      |              +----> cache              |
      |                                        |
      +----> background worker ----------------+

Each runtime uses a narrow workload identity and an explicit network path.

The API contract should use stable business language, clear validation, predictable error semantics, and an evolution strategy. A backend-for-frontend can tailor a contract to one client experience, but it should not become an unowned layer that duplicates business rules.

Choose a runtime based on deployment unit, scaling behavior, isolation need, startup and execution profile, portability requirement, and the team's operating capability. A managed application platform can remove host management. Containers can create consistent packaging and isolation. Functions can fit event-driven or bursty work. Kubernetes can provide a powerful orchestration boundary, but it also makes the team responsible for a larger platform. None of those choices determines whether the business design is modular.

Data Access Is an Authority Decision

Every runtime should have a workload identity with only the data permissions it requires. Prefer short-lived or platform-managed credentials where the provider supports them. Store unavoidable secrets in a controlled secret system and rotate them. Network privacy reduces exposure, but authorization still decides what a workload may do.

Keep the authoritative transaction path clear. A cache is a performance copy, not the system of record. A search index is a query model, not automatically an update authority. When components need independent ownership, use APIs, events, or replicated read models rather than cross-component writes to shared tables.

Example: Storefront Interior

A storefront API runs on a managed web platform. It validates requests and owns the order transaction in a relational store. A background worker consumes accepted order work and calls fulfillment integrations. A cache holds product summaries with an explicit expiry and invalidation path.

The API and worker scale differently and have different permissions, so they run separately. They may remain in one codebase and one owning team until independent release or ownership creates a reason to split further. That is a deliberate modular architecture, not a failed microservice architecture.

Common Mistakes

  • Splitting deployables before finding a valuable form of independence.

  • Giving every runtime the same broad database credentials.

  • Letting a gateway hide inconsistent contracts rather than fixing ownership.

  • Treating caches and indexes as authoritative without reconciliation rules.

  • Choosing an orchestration platform before the team can operate it safely.

If Someone Asks You

How do you choose boundaries behind an API gateway?

"I separate the caller contract from deployment and data ownership, then look for independent change, scale, failure, security, or team ownership. I keep components together when those benefits do not exceed the communication and operational cost of distribution."

What You Should Remember

Separate components when the responsibility gains from independence exceed the cost of distribution.

Questions to Check Your Understanding

  1. Why might API and deployment boundaries differ?

  2. What should a workload identity be allowed to access?

  3. When is a modular monolith the stronger architecture choice?

Further Study