Skip to content
Starone

Architecture

How the systems fit together

The diagrams we draw first when designing a system. Each one shows the layers or the flow, and the components that carry the load.

These are generalised patterns. A real design starts from your requirements and constraints and usually departs from the pattern in at least one important way.

Anatomy of a production AI application

Anatomy of a production AI application

  1. User

    • Web app
    • Mobile app
    • Chat interface
    • Internal tools

  2. Application Layer

    Owns identity, permissions and the user experience

    • Session handling
    • Access control
    • Response streaming
    • Feedback capture

  3. AI Orchestration Layer

    Where prompts, tools and policy are versioned and tested

    • Prompt management
    • Tool calling
    • Guardrails
    • Model routing

  4. Models / Agents

    • Hosted LLMs
    • Self-hosted models
    • Task agents
    • Embedding models

  5. Knowledge & Data Layer

    Retrieval respects the caller's permissions

    • Vector index
    • Document store
    • Relational data
    • Semantic cache

  6. Enterprise Systems / APIs

    • ERP and CRM
    • Identity provider
    • Internal APIs
    • Document repositories

  7. Infrastructure & Observability

    Traces, cost and quality measured per request

    • Kubernetes
    • GPU and API capacity
    • Tracing and evaluation
    • Cost monitoring
The layers between a user and a model in a production AI system. Most of the engineering effort sits in orchestration, knowledge, integration and observability, not in the model call itself.

The AI engineering lifecycle

The AI engineering lifecycle
  1. 01

    Data

    Collect, clean, label and govern sources

  2. 02

    Models

    Select, adapt and version models

  3. 03

    Orchestration

    Prompts, retrieval, tools, guardrails

  4. 04

    Applications

    Product surfaces and system integration

  5. 05

    Evaluation

    Offline test sets and online review

  6. 06

    Observability

    Traces, cost, latency and drift signals

Six stages that every production AI system passes through. Evaluation and observability feed back into data and models, so the loop is continuous rather than a single hand-over.

Retrieval-augmented generation pipeline

Retrieval-augmented generation pipeline

Ingestion

  1. 01

    Sources

    Documents, databases, internal APIs

  2. 02

    Parse and chunk

    Extract text, keep structure

  3. 03

    Embed

    Batch embeddings, versioned model

  4. 04

    Index

    Vector and keyword indexes with ACLs

Query

  1. 01

    Question

    Authenticated user and their scope

  2. 02

    Retrieve

    Hybrid vector and keyword search

  3. 03

    Rerank

    Keep only the strongest passages

  4. 04

    Generate

    Grounded answer with citations

  5. 05

    Evaluate and log

    Trace, score and capture feedback

Ingestion prepares enterprise content for search ahead of time. The query path retrieves, reranks and generates an answer that cites the passages it used, then records the exchange for evaluation.

Agentic workflow with human approval

Agentic workflow with human approval

Reason

  1. 01

    Trigger

    Event, schedule or user request

  2. 02

    Plan

    Break the goal into bounded steps

  3. 03

    Tool calls

    Read-only lookups via typed tools

  4. 04

    Draft action

    Proposed change with its evidence

Act under control

  1. 01

    Policy check

    Limits, permissions, risk rating

  2. 02

    Human approval

    Required for high-impact actions

  3. 03

    Act

    Idempotent write to target system

  4. 04

    Verify

    Confirm the result, retry or roll back

  5. 05

    Audit

    Every step logged and replayable

An agent plans and gathers evidence with read-only tools, then proposes an action. Writes pass through policy checks and, where the impact is high, a human approval before they execute and are audited.

Microservices architecture

Microservices architecture

  1. Clients

    • Web app
    • Mobile apps
    • Partner integrations

  2. API Gateway / BFF

    • Routing
    • Authentication
    • Rate limiting
    • Response shaping

  3. Domain Services

    Each service owns one bounded context

    • Orders
    • Payments
    • Catalogue
    • Accounts
    • Notifications

  4. Async Messaging

    • Kafka topics
    • Outbox publisher
    • Event consumers
    • Dead-letter queues

  5. Data Stores

    Database per service, no shared tables

    • PostgreSQL per service
    • Redis cache
    • Search index
    • Object storage

  6. Platform

    • Tracing and metrics
    • Central logging
    • CI/CD pipelines
    • Service configuration
Independently deployable services behind a gateway, each owning its data and communicating through events where a synchronous call is not required. The platform layer is what makes this many moving parts operable.

Event-driven architecture

Event-driven architecture

Producers

  1. 01

    Command

    Service handles a request

  2. 02

    Local transaction

    State and outbox row commit together

  3. 03

    Outbox relay

    Polls or tails the log, then publishes

  4. 04

    Publish

    Keyed event with schema version

Broker

  1. 01

    Topic

    One per event type or aggregate

  2. 02

    Partitions

    Ordering holds per key

  3. 03

    Retention

    Replay from an earlier offset

  4. 04

    Dead-letter queue

    Holds events that keep failing

Consumers

  1. 01

    Consumer group

    Scales out across partitions

  2. 02

    Idempotent handler

    Dedupe on event ID before applying

  3. 03

    Retry with backoff

    For transient faults only

  4. 04

    Commit offset

    After the side effect succeeds

  5. 05

    Project state

    Update read models and caches

Producers publish events through a transactional outbox, the broker preserves order per key, and consumers apply each event idempotently. Events that cannot be processed are parked in a dead-letter queue instead of blocking the partition.

Frontend rendering strategies

Frontend rendering strategies

Build time (SSG)

  1. 01

    Content and data

    CMS, Markdown or API read at build

  2. 02

    Static generation

    Pages rendered once to HTML

  3. 03

    CDN

    Cached and served from the edge

  4. 04

    Revalidate

    Regenerate on change or on a timer

Request time (SSR)

  1. 01

    Request

    Per-user or fresh data is needed

  2. 02

    Server render

    Fetch data, render components

  3. 03

    Streaming

    Send the shell, then slower parts

  4. 04

    Hydration

    Attach handlers in the browser

Client (SPA)

  1. 01

    Client state

    UI state and optimistic updates

  2. 02

    API calls

    Typed requests to the backend

  3. 03

    Cache

    Dedupe, revalidate, invalidate

  4. 04

    Navigation

    Client routing with prefetch

Where a page is rendered decides its speed, freshness and cost. Most products mix all three: static generation for stable content, server rendering for personalised or fresh data, and client state for interaction.

Mobile application backend

Mobile application backend

  1. Mobile Apps

    • iOS (Swift)
    • Android (Kotlin)
    • Flutter
    • Offline store

  2. Edge

    • CDN
    • API gateway
    • Authentication
    • Rate limiting

  3. BFF / Mobile API

    One round trip per screen where possible

    • Screen-shaped responses
    • API versioning
    • Sync endpoints
    • Feature flags

  4. Services

    • Accounts
    • Content
    • Payments
    • Media processing

  5. Data & Notifications

    • PostgreSQL
    • Redis
    • Object storage
    • APNs and FCM push

  6. Observability

    • Crash reporting
    • API tracing
    • Release health
    • Client analytics
Mobile clients talk to a backend-for-frontend that shapes responses for each screen and shields the apps from service changes. Old app versions stay in the field, so API versioning and release health are part of the architecture.

Cloud platform architecture

Cloud platform architecture

  1. Edge

    • DNS
    • CDN
    • WAF
    • DDoS protection

  2. Network

    Workloads and data sit in private subnets

    • VPC
    • Public and private subnets
    • Load balancers
    • NAT and peering

  3. Compute

    • Kubernetes
    • Containers
    • Serverless functions
    • Autoscaling

  4. Data

    • Managed databases
    • Cache
    • Object storage
    • Message queues

  5. Platform Services

    • Secrets management
    • IAM
    • Infrastructure as code
    • Container registry

  6. Observability & DR

    Restores are rehearsed, not assumed

    • Metrics and logs
    • Tracing
    • Backups
    • Multi-zone failover
A cloud foundation from the edge down to recovery. Each layer is defined as code, so an environment can be reviewed, reproduced and rebuilt rather than maintained by hand.

CI/CD pipeline with security gates

CI/CD pipeline with security gates

Build & verify

  1. 01

    Commit

    Reviewed merge to the main branch

  2. 02

    Build

    Reproducible, pinned dependencies

  3. 03

    Test

    Unit, integration and contract tests

  4. 04

    SAST and deps scan

    Static analysis, dependency audit

  5. 05

    Image scan and sign

    Scan layers, sign, attach SBOM

Release

  1. 01

    Staging

    Same artefact, production-like data

  2. 02

    Canary

    Small traffic share, watch signals

  3. 03

    Production

    Progressive rollout with gates

  4. 04

    Monitor

    SLOs decide promote or roll back

One artefact is built, verified, scanned and signed, then promoted unchanged through staging and a canary into production. Monitoring closes the loop by deciding whether a release is promoted or rolled back.

Security architecture: defence in depth

Security architecture: defence in depth

  1. Identity

    Every request is authenticated and authorised

    • SSO and MFA
    • Role-based access
    • Service identities
    • Session policy

  2. Edge

    • WAF
    • DDoS protection
    • TLS termination
    • Rate limiting

  3. Application

    • Input validation
    • Authorisation checks
    • Secure SDLC
    • Dependency scanning

  4. Data

    • Encryption at rest
    • Encryption in transit
    • Key management
    • Data classification

  5. Infrastructure

    • Network segmentation
    • Hardened images
    • Secrets management
    • Patch management

  6. Detection & Response

    Assume a control will fail and plan for it

    • Central audit logs
    • Alerting rules
    • Incident runbooks
    • Forensic retention
Controls are layered so that the failure of one does not expose the system. Identity is the outermost control and detection is the last, because prevention alone is never complete.

Web3 and digital asset infrastructure

Web3 and digital asset infrastructure

  1. Applications & APIs

    • Client applications
    • API gateway
    • Partner APIs
    • Operations console

  2. Wallets & Transactions

    • Address management
    • Transaction builder
    • Nonce and fee control
    • Policy engine

  3. Key Management

    Keys never leave the signing boundary

    • HSM
    • MPC signing
    • Approval quorum
    • Key rotation

  4. Node / RPC Layer

    • Full nodes
    • RPC providers
    • Failover routing
    • Mempool access

  5. Indexing & Analytics

    Chain data is provisional until it is final

    • Block ingestion
    • Event decoding
    • Reorg handling
    • Query APIs

  6. Monitoring & Compliance

    • Transaction monitoring
    • Address screening
    • Audit trail
    • Alerting
The off-chain systems that a digital asset product depends on. Smart contracts are a small part of the estate: custody, node access, indexing and monitoring carry most of the operational risk.

Modern data platform

Modern data platform

Ingest and store

  1. 01

    Sources

    Databases, SaaS tools, events, files

  2. 02

    Ingestion

    Batch, CDC and streaming

  3. 03

    Raw storage

    Immutable landing zone

  4. 04

    Lakehouse

    Open table formats or a warehouse

  5. 05

    Catalogue

    Schemas, lineage and ownership

Transform and serve

  1. 01

    Transform

    Versioned, tested SQL models

  2. 02

    Quality checks

    Freshness, volume and schema tests

  3. 03

    Serve BI

    Dashboards and governed metrics

  4. 04

    Serve APIs

    Data products for applications

  5. 05

    ML and embeddings

    Features and vector indexes

  6. 06

    Governance

    Access policy, masking and audit

Data moves from operational sources into governed storage, is transformed by versioned and tested models, and is served to analytics, applications and machine learning. Governance applies along the whole path, not at the end.

High-performance transaction platform

High-performance transaction platform

  1. Channels

    • Web
    • Mobile
    • Partner APIs
    • Batch files

  2. API Gateway

    • Authentication
    • Rate limiting
    • Idempotency keys
    • Request signing

  3. Transaction Services

    Java and Spring Boot, stateless, horizontally scaled

    • Payment initiation
    • Authorisation
    • Ledger posting
    • Limits and risk

  4. Kafka Event Backbone

    • Transaction events
    • Outbox relay
    • Partitioned topics
    • Dead-letter topics

  5. Ledger DB & Redis

    The ledger is authoritative, the cache is not

    • Double-entry ledger
    • Read replicas
    • Balance cache
    • Distributed locks

  6. Reconciliation & Audit

    • Settlement matching
    • Break detection
    • Immutable audit log
    • Reporting exports

  7. Monitoring

    • Latency and error SLOs
    • Consumer lag
    • Tracing
    • Business alerts
A transaction path designed so that the ledger is the single source of truth, events record every state change, and reconciliation independently confirms that the two agree.

Multi-tenant SaaS architecture

Multi-tenant SaaS architecture

  1. Tenant-aware Edge

    • Custom domains
    • Tenant resolution
    • WAF
    • Per-tenant rate limits

  2. Identity & SSO

    • SAML and OIDC
    • SCIM provisioning
    • Roles and permissions
    • MFA

  3. Control Plane

    Manages tenants, never serves their traffic

    • Tenant lifecycle
    • Plans and entitlements
    • Billing and metering
    • Feature flags

  4. Application Plane

    • Stateless services
    • Background jobs
    • Tenant context
    • Webhooks

  5. Data Isolation

    Isolation model chosen per plan tier

    • Row-level security
    • Schema per tenant
    • Dedicated databases
    • Per-tenant keys

  6. Per-tenant Observability

    • Usage metrics
    • Tenant-tagged traces
    • Noisy-neighbour alerts
    • Audit logs
A control plane manages tenants, plans and billing, while the application plane serves them. Tenant identity is resolved at the edge and carried through every layer down to the data store and the telemetry.

Real-world asset tokenisation flow

Real-world asset tokenisation flow

Off-chain

  1. 01

    Asset onboarding

    Legal structure and documents

  2. 02

    Investor KYC

    Identity and eligibility checks

  3. 03

    Asset registry

    Record of ownership and rights

  4. 04

    Reconciliation

    Registry matched to chain state

  5. 05

    Reporting

    Statements, audit and disclosures

On-chain

  1. 01

    Token issuance

    Mint against the registered asset

  2. 02

    Allowlist

    Only verified wallets can hold

  3. 03

    Transfer controls

    Rules enforced in the contract

  4. 04

    Settlement

    Atomic transfer against payment

  5. 05

    Lifecycle events

    Distributions, redemption and burn

The off-chain registry holds the legal record of the asset and its holders, and the on-chain token mirrors it under enforced transfer rules. Reconciliation keeps the two in agreement and feeds reporting.

Have a system that needs to work in production?

Tell us what you are building. An engineer will read it and reply within two working days.

Book a technical consultation