Skip to content

CONCEPT Cited by 1 source

Single-platform application architecture

A single-platform application architecture runs the application, the operational database, the analytical store, the ML/training substrate, and the natural-language-query surface inside one identity / governance / audit boundary, eliminating the integration layers that decoupled-tier architectures need to keep loosely synchronized.

The thesis (canonicalised in sources/2026-05-13-databricks-clinical-operations-intelligence-belongs-on-the-lakehouse): "Clinical operations teams do not need more dashboards connected to existing systems. They need their decision-support applications to live where their data and models live — so that the feedback loop between a prediction and the operational outcome that validates it actually closes."

The decoupled-tier shape this is contrasted against

Conventional decision-support stack:

[ Analytical warehouse / Lakehouse ]   ← long-lived analytical state
            │
            │  ETL / sync pipeline (lag, drift, retry, monitoring)
            ▼
[ Operational application database ]   ← per-app schema, separately
            │                              managed RDS, separate IAM
            │                              and credential rotation
            ▼
[ Web tier ]                          ← separate Kubernetes cluster,
                                         separate egress, separate
                                         secrets store

Each layer adds three classes of overhead the source explicitly names:

  • Integration overhead — every layer is a contract that has to be authored, monitored, and version-managed.
  • Credential surface area — every separately managed component needs its own auth posture and rotation lifecycle.
  • Synchronization lag — the time gap between "the data the model trained on" and "the data the application shows" erodes trust in the application's outputs.

Plus a fourth implicit overhead the post calls out — "semantic harmonization in the Silver layer" — when the warehouse model diverges from the application's view of the same entities.

The single-platform shape

Same application, composed inside one workspace boundary:

┌──────────────────────────────────────────────────────────────┐
│ Workspace (single identity + governance + audit boundary)    │
│                                                              │
│  Web app (workspace-resident, service-principal auth)        │
│     │ SQL Statement API (internal)                           │
│     ├─►  Unity Catalog ◄── Mosaic AI (training writes back)  │
│     │ REST API (internal)                                    │
│     ├─►  AI/BI Genie  (NL query against same UC tables)      │
│     │ Workspace identity                                     │
│     └─►  Lakebase  (operational state, scale-to-zero)        │
│                                                              │
│  No analytical↔operational sync pipeline.                    │
│  No external API surface.                                    │
│  No separately rotated credential store.                     │
│  Inheritance: app inherits UC access controls for free.      │
└──────────────────────────────────────────────────────────────┘

The four eliminations

The 2026-05-13 source articulates this as four specific layers becoming unnecessary (not abstracted, unnecessary):

  1. The sync pipeline. "A pipeline keeps them loosely synchronized." — gone. The app reads UC directly.
  2. The separate operational-DB credential surface. "A separately managed RDS instance with its own schema drift, sync jobs, and credential rotation" — gone. systems/lakebase is "provisioned and credentialed entirely within the workspace identity system."
  3. The web-tier-to-platform integration code. "Clinical operations data never crosses a workspace boundary. The app inherits Unity Catalog access controls without any additional configuration." The data-plane integration code that translated between UC's policy model and the app's RBAC model is gone.
  4. The semantic-harmonization layer. When the analytical store and the operational store have separate schemas, a Silver layer typically reconciles the two. With UC as the substrate the application reads from, that reconciliation is unnecessary.

The source's framing: "Databricks Apps, Lakebase, and AI/BI Genie eliminate each of those layers — not by abstracting them away but by making them unnecessary."

Why this enables a cleaner ML-audit substrate

The single-platform shape is what makes the SHAP-attribution-as-governed-Delta-table pattern coherent. When the application reads from UC, and the model writes its predictions plus SHAP attributions back to UC, the auditability chain is unbroken:

  • A regulator's question ("why was this site recommended?") becomes a SQL query against the same UC table the application read.
  • A fairness audit ("are community sites systematically under-weighted?") becomes a population-level SQL query against the attribution Delta table.
  • A model-version trace ("which model version produced this recommendation?") is one MLflow lookup followed by a UC lineage walk.

In a decoupled-tier architecture, the SHAP-attribution-Delta-table substrate exists but the application doesn't read from it directly — it reads from a synced operational copy, so the audit chain has a gap at the sync boundary.

Cousins, not synonyms

This concept is distinct from several adjacent ideas:

  • vs. concepts/lakehouse-native-observability — same spirit (telemetry-data-as-first-class-Lakehouse-asset), different altitude (observability storage vs. application runtime). Lakehouse-native observability puts logs/metrics/traces in Delta tables; single-platform application architecture puts the application that consumes those tables inside the same workspace.
  • vs. monolith-vs-microservices — orthogonal. The decoupled-tier shape this concept contrasts against can be a monolith (one app process) or microservices (many app processes); the load-bearing distinction is how many identity / governance / audit boundaries the composition crosses.
  • vs. data mesh — opposite altitude. Data mesh decentralises data ownership across domain teams; single-platform application architecture re-centralises the application around a unified data substrate. Both can coexist (data mesh on UC + apps on UC).
  • vs. concepts/compute-storage-separation — compute-storage separation is the storage-internals property (systems/lakebase uses it via Pageserver+Safekeeper). Single-platform application architecture is a higher-altitude composition property about which boundaries the application crosses. The two compose: Lakebase's compute-storage separation is what makes concepts/scale-to-zero viable, which is what makes Lakebase a good fit as the operational-DB layer in the single-platform shape.

When this shape is the right call

The 2026-05-13 source pitches the shape for regulated decision-support apps where the audit chain matters (clinical-trial site selection under FDORA 2022 + 21 CFR Part 11 + ICH E6(R3) + FDA GMLP). The general criteria:

  • The application's data is already in a governed analytical substrate. If the data lives elsewhere, the architecture devolves back into ingest-pipeline-plus-app-tier.
  • The audit chain matters more than the multi-platform portability story. Single-platform composition trades architectural coupling to the platform for audit-chain integrity.
  • The application is a thin layer over governed data and models. Decision-support apps fit; OLTP-heavy transactional apps don't — Lakebase scale-to-zero isn't optimised for sustained transactional load.

Seen in

Last updated · 542 distilled / 1,571 read