Skip to content

Architecture

How it's built

One diagram, then the patterns that hold it up. The shape below is the system as it actually runs — abstracted away from any specific vendor so you can read the design, not the marketing.

across availability zones
Multi-AZ
single contract, generated clients
OpenAPI
on every write path
Idempotency-Key
no hand-rolled drift
IaC per env

System shape

A boxes-and-arrows view of the running system. Solid edges are synchronous; dashed edges are asynchronous events.

Malai system architecture, abstracted Boxes-and-arrows view of the platform: external rails at the top connect through edge TLS termination and an API gateway, past an identity service, into four banking domains — account, cards, payments, audit — backed by a managed database, an event bus, and a managed object store. EXTERNAL RAILS FPS · BACS · SWIFT · CoP · Cards · Ledger Edge / TLS termination API gateway Identity Account domain Cards domain Payments domain Audit domain Managed database Event bus Managed object store LEGEND Synchronous request Asynchronous event

Topology & isolation

Where the system lives — replicated across availability zones, split across cloud accounts, and fenced at the module boundary so a stray call cannot cross a domain it shouldn't.

  • Cloud-native, multi-AZ

    Every primitive is a managed service the cloud operator runs across multiple availability zones. No single host owns state.

  • Environment isolation by account boundary

    Dev and prod live in separate cloud accounts with their own state, keys and credentials. A mistake in dev cannot reach prod data, and a dev-only credential cannot describe a prod resource.

  • Microservices with module fences

    Each banking capability is a discrete service with build-time fences that fail compilation when a call crosses a domain boundary it shouldn't.

  • Structurally non-authoritative AI reads

    The explanation capability deliberately has no internal client, so no service can consume its output as input to an action. The boundary is enforced at build time and recorded by an architecture test.

Services & contracts

How services talk to each other and to the database — synchronous where the caller needs an answer, asynchronous where coupling would force them to wait, and idempotent on every write path.

  • Event-driven where it matters

    Synchronous calls where the caller needs an answer; asynchronous events where coupling would otherwise force services to wait on each other.

  • Idempotency on sync and async paths

    Every write — request or event — carries an Idempotency-Key. Retries from clients, queues, and back-pressured workers all converge on the same result.

  • Two-tier database access

    The application runs under a least-privilege database role — INSERT/SELECT only on the audit log, no DDL anywhere. Migrations run under a separate, privileged role that the runtime never holds.

  • One chain core, two tenants

    The hash-chain mechanics behind the audit log are a shared core with a second tenant: the record of AI-assisted decisions. Same canonical serialisation, same verification, separate scopes.

  • Composed reads own no domain

    The executive dashboard is a fan-out over the domains that own the data, with a timeout per source and unavailability as a first-class state — it holds no tables of its own.

Edge & delivery

What a request meets before it reaches application code, and how credentials, certificates and headers are kept fresh without a maintenance window.

  • Edge cache layer with stamped security headers

    Every public origin sits behind an edge cache that enforces HSTS, a per-app Content-Security-Policy, X-Frame-Options and X-Content-Type-Options. A misconfigured application cannot strip them.

  • Automated credential rotation

    The database master credential rotates on a managed schedule. An event-driven redeploy picks up the new value without manual intervention and without a maintenance window.

Operations & change

How the platform is observed, reproduced and promoted — three pillars of telemetry, infrastructure expressed as code, and smoke tests against the deployed surface before promotion.

  • Three-pillar observability

    Distributed traces, RED-method metrics, and structured logs are emitted from every service and correlated by a single request id.

  • Infrastructure-as-code per environment

    A fresh environment — networking, compute, database, secrets, DNS — stands up from code in minutes. Drift between environments is a build break, not a guessing game.

  • CI/CD with smoke tests post-deploy

    Every merge to main flows through automated tests, builds an artefact, ships to dev, and runs a smoke pack against the deployed surface before promoting.