Architecture Overview

The six-layer system structure and full data flow across all components.

Table of Contents

  1. 2.1 Six-Layer Architecture
    1. Language Allocation
  2. 2.2 System Data Flow
  3. Key Data Flows
  4. 2.3 System Boundary
  5. 2.4 Reliability & Correctness Guarantees

2.1 Six-Layer Architecture

Layer Components Language
Layer 1 — Presentation React Web (Operator Workspace · Executive Dashboard) · React Native Mobile (Banker / RM) · React Web (Digital Banking Portal — treasury clients) · AI Assistant Panel (embedded, role-aware) TypeScript
Layer 2 — API Gateway Spring Boot GraphQL BFF · Spring Boot REST API · Domain services (Case · Product · Workflow · Audit · Metrics) · Portal API Gateway (customer-facing reverse proxy) · Notification Service WebSocket hub Java · Go
Layer 3 — Workflow Orchestration Temporal.io · ClientServicingWorkflow · ComplianceGateWorkflow · ProductProvisioningOrchestrator (multiple concurrent product workflows) · Signal-based human task pattern Java
Layer 4 — Agentic AI Python / FastAPI agent service · DocumentReviewAgent · CompliancePreFillAgent · AI Assistant · OCR · NLP · Anthropic Claude via MCP tool layer (framework TBD) Python
Layer 5 — Integration Services Spring Boot adapters — one per external system · Resilience4j circuit breaker · Retry · Dead-letter queues · OpenAPI 3.0 contract per system Java
Layer 6 — Data Amazon Aurora PostgreSQL (pgvector) · Amazon S3 (document store, 7-year retention) · Amazon ElastiCache Redis (session · agent memory) —

All layers run on Amazon EKS. Platform and DevOps teams interact via anchita-cli — a Go single-binary CLI wrapping the REST API.

Language Allocation

Language Runtime Components
Java 25 LTS JVM + Virtual threads (Project Loom) Temporal workers · Spring Boot APIs · Integration adapters · Domain services
Python 3 CPython + FastAPI AI agent service · LLM toolchain · DocumentReviewAgent · CompliancePreFillAgent
Go Native binary anchita-cli operations CLI · Notification Service WebSocket hub · Portal API Gateway
TypeScript Node.js / React Operator workspace · React Native mobile app

2.2 System Data Flow 

%%{init: {'theme': 'base'}}%%
flowchart TD
    classDef client      fill:#6d597a,stroke:#4a3f5c,color:#ffffff
    classDef aiService   fill:#e76f51,stroke:#bc4749,color:#ffffff,font-weight:bold
    classDef apiLayer    fill:#1d3557,stroke:#a8dadc,color:#ffffff
    classDef workflow    fill:#5c4a8a,stroke:#c77dff,color:#ffffff
    classDef dataLayer   fill:#2d6a4f,stroke:#52b788,color:#ffffff
    classDef integration fill:#e9c46a,stroke:#f4a261,color:#1a1a1a
    classDef external    fill:#6c757d,stroke:#495057,color:#ffffff
    classDef goService   fill:#457b9d,stroke:#a8dadc,color:#ffffff

    RM["📱 Banker / Relationship Manager\nReact Native"]:::client
    Operator["🖥 Operator Team\nReact Web Workspace"]:::client
    Channel["🌐 Digital Account\nOpening Channel"]:::client
    AIAssistant["🤖 AI Assistant\nPython · FastAPI"]:::aiService

    GQL["GraphQL BFF\nSpring Boot 3.x"]:::apiLayer
    REST["REST API\nSpring Boot 3.x"]:::apiLayer
    Notify["Notification Service\nGo · WebSocket hub"]:::goService

    Temporal["Temporal.io\nWorkflow Engine"]:::workflow
    Workers["Temporal Workers\nSpring Boot activity executors"]:::workflow

    Aurora["Amazon Aurora\nPostgreSQL"]:::dataLayer
    S3["Amazon S3\nDocument Store"]:::dataLayer
    Redis["Amazon ElastiCache\nRedis"]:::dataLayer

    IntSvc["Integration Services\nSpring Boot adapters"]:::integration
    ExtSys["External Systems\nmultiple target systems"]:::external

    RM --> REST
    Operator --> GQL
    Channel --> REST
    Operator <--> AIAssistant
    AIAssistant --> GQL
    AIAssistant --> IntSvc

    GQL --> Temporal
    REST --> Temporal
    GQL --> Aurora
    REST --> Aurora

    Temporal --> Workers
    Workers --> Aurora
    Workers --> IntSvc
    Workers --> S3
    Workers --> Redis

    IntSvc --> ExtSys

    Aurora -. "LISTEN / NOTIFY" .-> Notify
    Notify -. "WebSocket push" .-> Operator
Layer key     🟣 Client tier  ·  🟧 AI service  ·  🟦 API gateway  ·  🔵 Go services  ·  🟪 Workflow engine  ·  🟩 Data layer  ·  🟡 Integration adapters  ·  ⬜ External systems

Key Data Flows

New case intake (Banker via mobile): React Native → REST API → Temporal (start workflow) → Aurora (case record) → React workspace subscription fires

Operator approval (Document Review): React workspace → GraphQL mutation → workflow-service → Temporal signal → workflow advances → Aurora task written → workspace subscription fires

AI pre-fill (compliance questionnaire): Temporal workflow reaches compliance review phase → workflow-service calls agent-service REST → CompliancePreFillAgent runs OCR+NLP chain → pre-filled form written to Aurora → React compliance panel reads and displays

Integration failure recovery: Activity throws ApplicationFailure → Temporal routes to error recovery signal → Aurora error task created → React Error Recovery Panel surfaces task → operator submits decision → submitErrorRecovery signal → workflow resumes

2.3 System Boundary

Anchita is deliberately an orchestration and governance layer, not a clearing network. Stating the boundary explicitly keeps the design honest about what it owns and what it delegates.

In scope — the system of record and control plane

  • Immutable double-entry ledger — the authoritative record of balances and money movement (§9.4 / Data).
  • Durable workflow orchestration — every multi-step money movement and client-lifecycle process runs as a deterministic Temporal workflow (Temporal).
  • Client lifecycle & compliance gating — onboarding, KYC/AML gates, and multi-party payment approvals, with a human signer wherever regulation requires one.
  • Cross-cutting guarantees — end-to-end auditability, idempotency, and Saga-style compensation for distributed operations.

Out of scope — low-level clearing protocols

  • Generating binary / format-specific network packets — raw NACHA framing, ISO 20022 message packaging, or direct Fedwire socket handling.
  • Participating directly in clearing networks (Fedwire, SWIFT, DTCC), which require financial-institution licensing a reference architecture cannot hold.

How the boundary is enforced. External money movement is reached only through asynchronous partner-bank gateway interfaces — one versioned OpenAPI adapter per rail. The adapter owns the protocol specifics; Anchita owns the intent, state, and settlement lifecycle of the movement (see Payment Rails). This is precisely what lets the same workflow code run against a mock rail in the reference build and a real partner bank in production — only the adapter’s base URL changes.

Boundary invariant: Anchita records and orchestrates money movement; it never speaks a clearing network’s wire protocol directly. Every external rail sits behind an adapter with an OpenAPI contract.

2.4 Reliability & Correctness Guarantees

Because Anchita moves money across services, asynchronous boundaries, and external rails, correctness cannot rest on any single component behaving well. The design layers a small set of cross-cutting guarantees, each owned by the layer best placed to enforce it. Together they are what let the platform claim exactly-once financial effect under partial failure — the property a payments reviewer probes first.

Guarantee Failure it prevents Mechanism Detail
Durable execution Lost workflow state on crash or restart Temporal event-sourced history; human decisions are Signals, long waits are durable timers Temporal
Atomic ledger posting Partial or unbalanced money movement Immutable double-entry journal — Σ debits = Σ credits, or nothing persists Data
Exactly-once effect Duplicate postings from retries or redelivered webhooks Idempotency-Key → replay stored response; UNIQUE idempotency key at the data layer Data
Reliable event publication Dual-write skew — ledger committed but downstream event lost Transactional outbox written in the same DB transaction; CDC streams it onward Data
Compensated distributed ops A multi-step movement left half-done Saga pattern — every forward step has a balanced compensating entry Temporal
No money shown that can reverse Treating deferred / reversible-rail funds as final Settlement state machine; funds held until the rail confirms finality Payment Rails
Proven agreement with banks Internal ledger silently diverging from external reality End-of-day reconciliation; every break becomes a human task Reconciliation
Fault isolation One failing downstream cascading across the platform Resilience4j circuit breakers + one adapter per system boundary (bulkhead) Integration
End-to-end traceability Blind debugging across asynchronous hops OpenTelemetry / W3C trace context propagated through Temporal into activities Infrastructure

None of these is bolted on as an afterthought — each lives in the layer that owns the risk, which is why the guarantee still holds as the system grows.

↑ Back to top

Anchita Banking — Fictional Reference Architecture for Cloud-Native Institutional Banking