Architecture

How ArayaThrust is built, how data moves through it, and what protects each boundary. Scoped to the implemented platform.

Scope of this page

This describes the architecture that is deployed today: the public site and the subscription, onboarding and transactional-email system behind it. The clinical application layer is not covered, because there is no implementation to describe. Documentation marks the same boundary.

Architecture overview

The system is deliberately small and sharply divided. The public site is fully static, so the web tier has no application server and no database connection. Everything transactional happens behind a single API gateway, which routes each path to its own isolated function.

One principle shapes the rest: the browser is never the authority on anything that grants entitlement. Payment status arrives from the provider to the server over a signed channel and is re-confirmed before it is acted on. That is why the architecture has a webhook path that the customer’s browser never touches.

High-level diagram

Zoom, scroll or expand the diagram to full screen. A full text description is available to screen readers, and the component table below carries the same information in prose.

High-level architecture
100%
ArayaThrust high-level architectureA visitor's browser loads the statically hosted marketing site from a CDN. For transactional actions the browser calls an HTTP API gateway, which routes each path to its own isolated serverless function. Those functions use a key-value store for short-lived records, an email service for transactional mail, and the Paystack API to confirm charges. Paystack independently calls the webhook function with a signed charge event. After confirming a charge, the webhook mints a single-use token that the customer portal exchanges server-to-server. The full component list is in the table below this diagram.ARAYATHRUST CLOUDVisitor browserPublic websiteStatic siteCDN-hosted exportHTTP API gatewayPOST routes, throttledSignup & email fnsHandoff fnsPayment webhookKey-value storeTTL recordsEmail serviceDKIM-signed domainPaystackCharges & verificationCustomer portalSeparate applicationTeam inboxEnquiries & alertsrequestauthenticated / internalthird partyseparate ArayaThrust app

Component architecture

ComponentResponsibilityNotes
Static siteServes the public website and checkout UI.Pre-rendered at build time and served from a CDN. No server rendering, so there is no application server to attack at the web tier.
HTTP API gatewaySingle public entry point for transactional calls.POST-only routes, CORS restricted to configured origins, throttled at 10 requests per second with a burst of 20.
Serverless functionsOne isolated function per route.Each has its own permissions and its own log stream, so a fault in one route cannot affect another.
Key-value storeShort-lived operational records.Verification codes, webhook idempotency claims and handoff tokens. Every record carries an expiry and is removed automatically.
Email serviceTransactional mail on an authenticated domain.DKIM signing and a dedicated MAIL FROM subdomain, so sending alignment is independent of the mailbox provider. Delivery events publish to a monitoring topic.
Payment providerTakes payment and confirms charges.Third party (Paystack). Card data never touches ArayaThrust infrastructure — payment is completed in the provider's own frame.
Customer portalAuthenticated subscriber application.A separate ArayaThrust application. It receives verified identity and plan through the handoff exchange rather than trusting any browser-supplied value.

Data flow architecture

Four flows account for essentially all traffic. Each is described by what crosses a boundary, since that is where the security properties live.

FlowPathWhat is trusted
EnquiryBrowser → gateway → function → email service → team inboxNothing. Input is treated as untrusted text and escaped before it is rendered into an email.
Email verificationBrowser → gateway → function → store, and function → email servicePossession of the mailbox. The stored code is hashed with a server-side pepper, so the record alone does not yield a usable code.
Payment confirmationPaystack → gateway → webhook function → Paystack API → store → email serviceA signature over the raw body, then a second confirmation fetched directly from the provider. The inbound payload alone is never sufficient.
Account handoffPortal backend → gateway → function → storeA shared key on a server-to-server call, plus a single-use token that is burned on redemption.

Security architecture

  • Transport: TLS for all site and API traffic.
  • At rest: managed-service encryption for every stored record; the payment secret is held as an encrypted environment value, never in the site bundle or version control.
  • API surface: POST-only routes, origin-restricted CORS, and gateway throttling shared across all callers.
  • Webhook authenticity: HMAC SHA-512 over the raw body, compared in constant time, followed by an independent re-confirmation with the provider.
  • Replay and duplication: each payment reference is claimed once; the claim is released only on transient failure so a provider retry can still complete.
  • Handoff: opaque single-use tokens with a seven-day expiry, redeemed conditionally so concurrent attempts cannot both succeed.
  • Data minimisation: short-lived records expire automatically rather than accumulating.
  • Separation: one function per route, each with only the permissions that route needs.

Deliberately not published here

Resource identifiers, internal hostnames, function and table names, account identifiers and specific security configuration are omitted. They add nothing for an evaluator and would narrow the work of an attacker. Enterprise customers who need that depth under NDA should contact customercare@arayathrust.com.

Single sign-on and role-based access controlPlanned

SSO and RBAC are portal concerns. The handoff carries a verified email, the purchased tier and the role captured at signup; what those grant is defined by the portal, which is outside this repository and therefore outside this page.

Deployment architecture

  • Hosting: the site is built from the main branch and published as a static export to a managed CDN host. Build-time configuration is injected as environment variables, so changing one requires a rebuild to take effect.
  • Backend: infrastructure is declared as code and applied deliberately, so the deployed shape matches a reviewed definition rather than accumulated console changes.
  • Region: backend services run in a single AWS region in Europe (eu-west-2), with the static site distributed globally by CDN.
  • Scalability: both the CDN and the serverless functions scale horizontally on demand; the gateway throttle is the deliberate ceiling.
  • Availability: the site has no application server at the web tier, so it remains readable even if backend services are degraded — only transactional actions would be affected.
  • Environment separation: payment test and live modes are configured separately, and the key pair in use determines which the system is operating in.

Requesting more detail

Procurement and security reviews often need more than a public page should carry — data processing specifics, retention schedules, sub-processors, or a architecture walkthrough. Email customercare@arayathrust.com and we will arrange it under NDA.