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 three banking domains — account, payments, audit — backed by a managed database, an event bus, and a managed object store. EXTERNAL RAILS FPS · BACS · SWIFT · CoP · Ledger Edge / TLS termination API gateway Identity Account 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.

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.

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.