Reference cloud architecture

This note sketches the production topology for Larkfield, a hypothetical SaaS web application. It runs as a conventional three-tier system on AWS: a public edge that terminates traffic and routes requests, a stateless application tier that holds the business logic, and a managed data tier for durable storage and search. A separate support tier handles object storage and observability. The diagram below is rendered live by NoteThink from a fenced Mermaid block - nothing is a screenshot.

System topology

architecture-beta
    group edge(logos:aws-cloudfront)[Edge Layer]
    group app(logos:aws-lambda)[Application Layer]
    group data(logos:aws-rds)[Data Layer]
    group support(logos:aws-s3)[Support and Observability]

    service cdn(logos:aws-cloudfront)[CloudFront CDN] in edge
    service gw(logos:aws-api-gateway)[API Gateway] in edge

    service api(logos:aws-lambda)[Request Handlers] in app
    service worker(logos:aws-ec2)[Worker Fleet] in app

    service db(logos:aws-rds)[Primary Database] in data
    service search(logos:aws-open-search)[Search Cluster] in data

    service assets(logos:aws-s3)[Asset and Backup Store] in support

    cdn:R --> L:gw
    gw:R --> L:api
    api:R --> L:worker
    api:B --> T:db
    api:R --> L:search
    worker:B --> T:assets
    db:R --> L:assets

Components and roles

• CloudFront CDN - terminates TLS at the edge, caches static assets, and forwards dynamic requests inward.
• API Gateway - the single ingress for the application tier; handles auth, throttling, and request routing.
• Request Handlers - stateless Lambda functions serving the synchronous API surface.
• Worker Fleet - EC2-backed workers draining the async job queue (image processing, exports, scheduled jobs).
• Primary Database - managed RDS instance holding the transactional system of record.
• Search Cluster - OpenSearch serving full-text and faceted queries, kept in sync from the database.
• Asset and Backup Store - S3 buckets for user uploads, generated artifacts, and database snapshots.

Request flow

The happy-path read request traverses the tiers as follows.

flowchart LR
    U[Browser] --> C[CloudFront]
    C --> G[API Gateway]
    G --> H[Request Handlers]
    H --> D[(Primary Database)]
    H --> S[(Search Cluster)]
    H --> C
    C --> U

A cache miss at CloudFront falls through to API Gateway, which invokes a Request Handler; the handler reads from the database or search cluster, returns a response that CloudFront caches, and the browser is served. Writes follow the same edge-to-app path but fan out to the worker fleet and asset store for any heavy or deferred work.

Demonstrates NoteThink's Mermaid architecture-beta rendering - cloud topology with provider logo icons, drawn inline from a fenced code block.