Skip to content

Architecture

This is a proposed system architecture rather than a description of already-running infrastructure.

Explore the interactive C4 diagrams to drill from system context into mobile and API components.

Boundary Planned implementation Responsibilities
Mobile React Native / TypeScript Daily Word, Practice, local learning, user experience
Local storage SQLite and immutable files Evidence, resumable encounters, preferences, installed content
API Node.js / TypeScript Optional auth, sync, user settings, canonical replay, analytics
Cloud database Azure SQL Signed-in canonical evidence, identities, sessions and materialised state
Static content Cloudflare R2 Version-addressed word packs, Daily schedules and recordings
Identity Apple and Google Optional sign-in tokens
Telemetry Azure Monitor / Application Insights Restricted operational/product signals
  • No online round trip is needed for spelling interactions.
  • A shared deterministic learning-engine package is linked into both the mobile client and server, not deployed as a third microservice.
  • Learning evidence is immutable, ordered and idempotently merged, not resolved by indiscriminate last-write-wins.
  • Cloud sign-in and synchronisation remain optional for normal use.
  • The API does not serve bulk audio or static versioned word data.
  • Regional spelling acceptance is editorially specified; runtime must not guess legitimate spelling alternatives.
  • Native app UI testing needs its own device/simulator strategy beyond browser-oriented Playwright coverage.

Implementation plan · Data model · Persistence and sync · Machine-readable contracts · Research decisions · Acceptance guide.

The editable Structurizr DSL model is validated and exported automatically. The site uses an interactive static viewer and retains reusable SVG exports.