architecture.artof.link
Site menu

System Architecture & Stack

This page is the high-level technical map of the cloud infrastructure, services, and client applications that power the Adaptive Experience.

In Plain English: When a customer orders flowers online, what happens behind the scenes? This page explains how our cloud servers, secure gateways, event message streams, databases, and mobile apps connect together. It shows how we keep customer interactions fast and private, prevent web browsers from ever touching raw databases, and keep our documentation completely separate from the live shop.

Two hostnames · Documentation site · Florist runtime · System architecture · Request flow · Mobile companion · Honesty ledger

Two Hostnames, Two Jobs

To prevent interference and ensure high reliability, we operate two distinct public domains:

These two sites do not share a server, database, or load balancer. If the shop receives heavy traffic, the architecture site is completely unaffected, and vice versa.

Knowledge is not a shop path. /native and /framework on aea.artof.link are not published documentation pages. Read companion and Path B notes here.

Two hostnames: framework site and florist case study

The Documentation Site

The framework site at architecture.artof.link is built entirely from verified markdown files in this repository.

The Florist Shop Runtime

The flower shop at aea.artof.link is a real-world Path B deployment of the Adaptive Experience formula (pilot evening demo window — see honesty ledger):

  1. Secure Perimeter (TLS Edge & BFF): Web browsers and mobile apps communicate exclusively with a Backend-for-Frontend (BFF) over encrypted HTTPS. Browsers are never allowed to query databases directly.
  2. Event-Driven Orchestration: User actions (such as selecting a bouquet or adding a card message) are published to a contract-first, Kafka-compatible message bus.
  3. Authoritative Domain Services: Independent services handle catalog lookups, inventory verification, pricing rules, delivery slot allocation, and order creation. They write directly to a secure PostgreSQL database.
  4. Isolated AI Gateway: Conversational models sit securely behind a model gateway on a private network, interpreting customer intent without possessing write access to customer financial records.
  5. Cloud Infrastructure: Hosted in AWS (us-east-1) via committed Terraform templates, utilizing ECS Fargate container clusters, Application Load Balancers, and managed PostgreSQL. A local Docker Compose environment mirrors this exact architecture for developer testing.

System Architecture (High-Level Design)

The diagram below illustrates how web shoppers and mobile companion apps connect through the TLS Edge and BFF into the orchestration bus and core services:

Path B high-level design as used so far

Request Flow: From Browser to Database

This diagram shows how a customer request travels from left to right: from the client's screen, through perimeter security checks, into orchestration, across the message bus, and down into authoritative domain databases:

Path B as-is flow from clients through TLS edge, BFF, orchestration, bus, and domain services

The Mobile Companion App

The Android companion is an alternative mobile client designed for fast on-the-go orders. It connects to the same backend and domain services as the website:

Path B to-be high-level design with a native Android companion on the same BFF

Honest Status Ledger

Every capability mentioned on this site is classified by its verified production status:

Two Public Hostnames — Independent infrastructure: architecture.artof.link (documentation, GitLab Pages — stays as-is) and aea.artof.link (shop pilot). Shop probes succeed by default only in the evening demo window (20:00–22:00 Europe/Berlin) or during an active short wake lease; off-window failures are scheduled, not incidents.

>

Backend Domain Services — Deployed on AWS ECS (pilot schedule): PostgreSQL, Kafka-compatible event streaming (MSK), and Edge BFF exist on AWS ECS Fargate for the pilot. App services follow the evening/on-demand schedule (Documented until schedule Lambda probed). MSK and NAT stay up in phase 1 — do not claim they hibernate with the app tier.

>

Google Play Mobile Distribution — Probed (4 Sep 2026, version 5): That 4 Sep Play Internal take remains a historical probe (#390). Later Play Internal versions and the named-handset ledger live on the companion page. This row does not restate those later dumps.

>

Mobile Order Write-Through — Probed (4 Sep 2026): Orders placed in the companion app write through to the store's central database and appear in real time on the florist dashboard with client: companion-android (Order 34091114-cb91-44de-a5a3-6be78c503912, #375, #384).

>

Payment Processing — Deterministic Simulation: Real credit card charging is not connected. Payment is safely simulated via an in-memory payment engine under ADR-016.

>

Dual-Viewport Layout Proof — Unknown: While responsive CSS has merged, a complete side-by-side journey recording showing desktop (16:9) and phone (9:16) working simultaneously has not yet been captured.

>

Operator Dashboard vs. Commercial Billing — Operational Distinction: The sample florist order screen provides order fulfillment visibility, but is not a replacement for an external enterprise billing ERP.