12. Runtime architecture

Walk through the visual explanation →

Separate provider responsibilities

Cloudflare owns edge and control-plane responsibilities: ingress, static delivery, request protection, coordination and selected public caching and collaboration services. These are different from canonical identity and domain records.

The application’s Next.js Node runtime runs on Google Cloud Run behind the edge. Domain services execute commands and queries. Firebase and Google Cloud provide Firebase Auth, Firestore, Storage, App Check, Functions and selected workloads. External providers remain adapter boundaries.

A conceptual request

A client uses an explicit transport. The request boundary admits and routes the request. Authentication establishes identity. Authorization evaluates current scoped authority. A domain command or query performs the relevant work through storage or provider adapters. The response exposes an authorized projection.

This path is conceptual rather than a literal published inventory of routes, headers and deployment configuration. Actual handlers and adapters retain their distinct implementation concerns.

Background execution

Some effects belong outside the interactive request. Durable admission connects a committed domain change to later processing. Jobs may retry, and providers may fail independently. Admission is evidence that processing was accepted, not proof of successful delivery.

This separation makes failure interpretation more useful. A successful application command, a pending effect and a delivered provider message are different outcomes. The user-facing interface should describe the one actually established.

Operational tradeoffs

The edge/origin boundary introduces coordination across provider roles and releases. The Node-capable origin supports application and provider work that is not reduced to static edge behavior. The chosen split should be evaluated against its responsibilities, rather than treating one provider as a synonym for the whole platform.

The provider map is source-backed documentation. This public case study does not independently verify live settings, every release path or all tenant-domain transitions. It describes architecture and its evidence limits, not private operations.