Platform Overview

What Anchita is, why it was designed this way, and the core architectural decisions that shape everything else.

What Is Anchita?
1.1 Design Goals
1.2 Core Design Decisions
1.3 Design Motivations
1.4 What I’m Building and Learning

⚠️ Fictional reference architecture — all system names, product counts, and business details are entirely invented for learning purposes.

What Is Anchita?

Anchita is a cloud-native platform for the institutional banking client lifecycle and payments, designed from first principles to serve commercial banking clients across all segments — Small Scale, Medium Scale, and Enterprise — through a single, coherent workflow engine, one unified data model, and one consistent operator experience.

Anchita Platform — built around the idea that every operator should have an intelligent co-pilot at every step of the servicing workflow.

1.1 Design Goals

Goal	Implementation
Unified client servicing	Single `ClientServicingWorkflow` on Temporal.io handling all segments
Modern operator experience	React workspace with role-aware panels + React Native mobile
Durable case records	PostgreSQL case records on Amazon Aurora
Clean integration contracts	Spring Boot services with versioned OpenAPI specs
AI-assisted operations	AI Assistant agent network (Python / FastAPI — framework TBD)
Mobile-first banker access	React Native mobile app for bankers and relationship managers
SLA visibility	Built-in metrics pipeline → Operations Dashboard

1.2 Core Design Decisions

Segment routing model (SMALL, MEDIUM, ENTERPRISE) — the clientSegment flag is the master routing switch set at case intake and never changed. It drives workflow phase inclusion, UI panel visibility, product eligibility, and provisioning paths. Rather than scattering if (segment == ENTERPRISE) conditionals throughout the codebase, each segment is expressed as a WorkflowConfig record — making the differences explicit, testable, and visible in one place.

Five-tier workflow architecture — the main ClientServicingWorkflow orchestrates up to 8 phases. Specialised sub-processes (Compliance Gate, Product Provisioning) are modelled as Temporal child workflows, giving clean separation of concerns. Each workflow type has its own Task Queue and worker pool, which can be independently scaled.

Product coverage matrix — 23+ treasury product operations are implemented as independent Temporal child workflows, fan-out capable via Promise.allOf(). Adding a new product means adding one child workflow implementation — the orchestrator does not need to change.

Non-negotiable compliance gates — BSA/AML (Bank Secrecy Act / Anti-Money Laundering) attestation and Document Review are mandatory human review steps. The AI Assistant agents pre-fill and assist but cannot auto-approve either step. This is not a configuration flag — it is a hardcoded architectural boundary enforced by the signal type:

Under 31 USC 5318(g), a BSA Officer must personally attest. The submitBSAAttestation signal requires a human actor; the ai_auto_approved flag is blocked for this task type in the workflow implementation.

OpenAPI integration contracts — every external system interaction is defined as a versioned OpenAPI 3.0 spec. Integration adapters are independently deployable Spring Boot services. The same contract governs mock/test environments and production — only the base URL changes.

1.3 Design Motivations

Client onboarding in institutional banking has historically faced a common set of systemic problems — limitations widely documented across legacy BPM/BPMN platforms. Anchita is designed to address each one directly:

Problem	Anchita Approach
Fragmented operator experience — a different screen for every step with no unified case view	Three-panel React workspace (Queue · Case Detail · AI Assistant) — persistent across all screens
Operators manually check documents, fill questionnaires, and look up client data from separate systems	AI Assistant agents pre-fill, flag, and suggest — operators review and confirm
Integration logic concentrated in a single gateway, with few resilience patterns	One dedicated Spring Boot adapter per system — circuit breaker, retry, dead-letter per adapter
Small, Medium, and Enterprise clients handled by separate process definitions	One `ClientServicingWorkflow` — segment routing via `WorkflowConfig` record
Long-running cases prone to failure with no recovery story	Temporal.io: durable workflow execution survives restarts; operator error recovery via signal
No structured audit trail for compliance review decisions	Immutable `audit_events` table — every human and AI action logged with actor, timestamp, and payload
Long-running activation waits block worker threads	Temporal timer — no worker consumed during wait; KEDA scales workers on actual task queue depth

1.4 What I’m Building and Learning

This project is my hands-on exploration of a stack I’ve long wanted to master in a domain I know deeply — institutional banking. Specifically:

Temporal.io — durable workflow orchestration as a first-class engineering pattern, not an afterthought. Replacing legacy event-based workflow orchestration with Temporal signals, child workflows, and durable timers.
Agentic AI in regulated environments — how to apply LLMs meaningfully without removing human accountability where regulations require it. The 3-state confidence framework (silent pre-fill / flagged pre-fill / chat-only) is the practical expression of this boundary.
GraphQL as a BFF — role-aware query design for complex operational UIs. The workspace BFF exposes a schema that maps directly to the case model and workflow state, enabling the React workspace to be fully declarative about what it needs.
Event-driven integration at scale — resilience patterns (circuit breaker, retry, dead-letter) applied consistently across all heterogeneous external system adapters. Every integration failure surfaces to the operator workspace as an actionable error recovery task.
KEDA-based autoscaling — scaling Temporal workers based on actual task queue depth, not CPU guesses. During peak onboarding, product provisioning workers scale out automatically; long-running activation waits become durable timers, not blocking threads.
Modern Java 25 LTS — records, sealed interfaces, pattern matching, and virtual threads (Project Loom) applied to real domain modelling. Virtual threads are particularly relevant for Temporal worker concurrency — thousands of concurrent blocked workflow coroutines without OS thread exhaustion.
React + React Native — a single team owning both the operator web workspace and the banker mobile app. ~60–70% shared logic; Ant Design for the operator-facing enterprise tables and forms.
Go for the right workloads — learning when to reach for Go rather than defaulting to Java or Python everywhere. Two components make the case: anchita-cli, a single-binary operations tool that platform and DevOps teams can run without any runtime dependency; and the Notification Service, a WebSocket hub where Go’s goroutine model handles thousands of concurrent idle connections at a fraction of the RAM that a Spring Boot thread-per-connection approach would require. The goal is not to use Go for its own sake, but to understand concurrency primitives, static binary distribution, and the cloud-native CLI ecosystem that Go dominates — kubectl, helm, argocd, and the Temporal CLI itself are all Go.

Next: Architecture Overview — the six-layer system and data flow diagram.