HattaDev
Menu
Fintech

Digital Banking Backend Platform — Secure Microservices Architecture

ClientPT Bank Rakyat Indonesia Tbk
Year2026
Stack12 technologies
Scroll
Results & Impact

Key Performance Metrics

99.99

Uptime

15

Time Saved

Business Challenge

The digital bank needed to launch in 8 months with a complete banking stack — customer onboarding with e-KYC, core banking with real-time ledger, payment processing with BI-FAST and QRIS integration, lending with automated credit scoring, regulatory reporting to OJK, and compliance with PCI DSS and GDPR-equivalent regulations. The existing options — buying a legacy core banking system or building on a vendor platform — were rejected due to high licensing costs and limited customization. The bank chose to build a custom platform to maintain competitive differentiation and avoid vendor lock-in.

## Solution Architecture

Solution Architecture

We designed a domain-driven microservices architecture with 12 bounded contexts: Customer, Account, Transaction, Payment, Lending, Card, Notification, Audit, Reporting, Identity, Configuration, and Gateway. Each service owns its database schema in a shared PostgreSQL cluster with logical separation enforced at the application layer. Inter-service communication uses Apache Kafka for asynchronous events and gRPC for synchronous calls requiring immediate consistency. An API Gateway (Kong) provides centralized authentication, rate limiting, request transformation, and API versioning.

### Transaction Processing Pipeline

Transactions flow through a multi-stage pipeline designed for correctness under failure: API Gateway validates JWT and rate limits → Transaction Service validates business rules (sufficient balance, account status, limits) → creates a pending transaction in the ledger → publishes TransactionInitiated event to Kafka → Account Service updates balance (optimistic locking with version field) → Payment Service routes to external network (BI-FAST, QRIS) → publishes TransactionCompleted event → Notification Service sends push notification. Every state transition is logged immutably to the audit service. Failed transactions trigger compensating actions via the Saga pattern.

### Security Architecture

**Defense in Depth:** Network segmentation with Kubernetes network policies isolating services by trust level. mTLS between all services using HashiCorp Vault for certificate management. JWT with short-lived access tokens (15 minutes) and refresh token rotation. API keys hashed with SHA-256 for service-to-service authentication. All sensitive data (PII, account numbers) encrypted at the application layer before storage using AES-256-GCM with per-customer encryption keys. HSM integration for cryptographic key management. OWASP ASVS Level 2 compliance verified through independent penetration testing.

## Key Features

Key Features

Customer onboarding with e-KYC integration (Dukcapil verification, biometric liveness detection, OCR document scanning). Core banking with double-entry ledger, real-time balance computation, transaction categorization, and monthly statement generation. Payment processing with BI-FAST (real-time), QRIS (merchant-presented and customer-presented), virtual account, and interbank transfer via SKN. Lending with automated credit scoring, loan origination workflow, disbursement, repayment scheduling, and collections management. Regulatory reporting with automated OJK reports (LBU, LKPBU), suspicious transaction monitoring, and audit trail with cryptographic integrity.

## Technology Stack

Technology Stack

Java 21 with Spring Boot 3 for core banking microservices — chosen for its mature ecosystem, strong typing, and enterprise-grade transaction management. Apache Kafka for event streaming with exactly-once semantics for financial events. PostgreSQL 16 for transactional data with connection pooling via HikariCP and read replicas for reporting queries. Redis for distributed caching, session management, and rate limiting. HashiCorp Vault for secrets management, encryption-as-a-service, and PKI. Kong API Gateway for centralized routing, authentication, and rate limiting. Docker and Kubernetes for container orchestration with pod anti-affinity for high availability. Prometheus and Grafana for metrics, OpenTelemetry for distributed tracing, ELK stack for centralized logging.

## DevOps Pipeline

Results

Platform launched on schedule in 8 months. Processes 10,000+ transactions per second with p99 latency under 200ms. Achieved 99.99% uptime (less than 53 minutes downtime per year). PCI DSS Level 1 compliance certified on first audit. Customer onboarding time reduced from 3 days (manual) to 5 minutes (automated e-KYC). Loan approval time reduced from 5 days to 2 minutes through automated credit scoring.

## Lessons Learned

Lessons Learned

Microservices architecture requires significant investment in observability — distributed tracing was essential for debugging transaction failures across 12 services. The Saga pattern is necessary for cross-service transactions but adds complexity — every forward operation needs a corresponding compensating transaction with idempotency guarantees. API versioning must be designed from day one — breaking changes to internal service contracts cascade through the entire platform. Financial software demands a different level of testing rigor — we implemented property-based testing for transaction validation, chaos engineering for failure injection, and parallel run validation comparing new system output against manual calculations for 3 months before go-live.

Technology Stack

Technologies Used

JavaSpring BootApache KafkaPostgreSQLRedisHashiCorp VaultKongDockerKubernetesPrometheusGrafanaOpenTelemetry
More Work

Related Projects

Enterprise Software

Manufacturing ERP Platform — Enterprise Production Management

A cloud-native Enterprise Resource Planning system built for a multi-factory manufacturer producing 50,000+ SKUs across 8 production lines. The legacy system — a combination of Excel spreadsheets, disconnected Tally installations, and paper-based quality control — was causing production delays, inventory discrepancies, and financial reporting that lagged 2-3 weeks behind actual operations. ## Business Challenge The manufacturer operated 3 factories across Java with 2,000+ employees and a complex supply chain involving 300+ raw material suppliers. Each factory ran its own spreadsheet-based production schedule with no real-time visibility into material availability, work-in-progress status, or quality metrics. Procurement was reactive rather than planned, resulting in both stockouts stopping production lines and overstock tying up working capital. Financial consolidation required 5 accountants spending 10 days per month reconciling data from three separate systems. ## Solution Architecture We designed a modular ERP platform with bounded contexts for Production Planning, Inventory Management, Purchasing, Warehouse Management, Quality Control, Finance, and Executive Analytics. Each module operates as an independent service communicating through Apache Kafka for event-driven data synchronization. The system uses CQRS with PostgreSQL as the write store and Redis-powered read projections for real-time dashboards. The architecture enforces eventual consistency across modules while maintaining ACID transactions within each bounded context. ### Key Architecture Decisions **Event-Driven Integration:** All state changes are published as domain events (ProductionOrderCreated, InventoryReserved, QualityCheckPassed) to Kafka topics. Downstream services consume these events to maintain materialized views. This ensures loose coupling — the Quality Control module can be deployed independently without affecting Production Planning. **CQRS Pattern:** Write operations go through command handlers that validate business rules against the PostgreSQL write model. Read operations query denormalized Redis projections optimized for specific UI views — the production dashboard reads from a pre-computed projection updated in real-time via Kafka consumers, not from raw transactional tables. **Multi-Tenancy at Database Level:** Each factory operates within its own PostgreSQL schema, providing data isolation while sharing the same application infrastructure. Cross-factory reporting uses a dedicated analytics database populated through Kafka Connect. ## Key Features Production Planning with finite capacity scheduling considering machine availability, labor shifts, and material constraints. Inventory Management with real-time stock tracking across 8 warehouses using barcode scanning. Purchasing with automated purchase requisition generation based on reorder points and production schedules. Quality Control with inspection workflow, non-conformance tracking, and supplier quality scorecards. Finance with automated journal entries, multi-factory consolidation, and Indonesian tax compliance (e-Faktur integration). BI Dashboard with real-time OEE (Overall Equipment Effectiveness), production variance analysis, and cost-per-unit tracking. ## Technology Stack Frontend built with Next.js 15 App Router and React Server Components for island architecture — interactive dashboards render client-side while static reports use server components. Backend API layer built with NestJS following Clean Architecture with use cases, repositories, and domain entities. PostgreSQL 16 for write models with table partitioning for high-volume tables (production transactions, inventory movements). Redis Cluster for caching read projections and session management. Apache Kafka for event streaming between bounded contexts with exactly-once semantics. Docker containers orchestrated with Kubernetes on AWS EKS. Infrastructure as Code with Terraform managing VPC, RDS, ElastiCache, MSK, and EKS. ## Security Architecture Role-based access control with 12 permission roles mapped to factory-level and module-level scopes. JWT authentication with refresh token rotation. Audit logging on every state mutation with tamper-evident hashing. Data encryption at rest using AWS KMS and in transit using TLS 1.3. Network segmentation between application tier, database tier, and message broker tier using Kubernetes network policies and AWS security groups. ## Scalability Design The system is designed to handle 50,000+ production transactions per day with peak loads during shift changes. Horizontal Pod Autoscaling on Kubernetes scales API services based on CPU and custom metrics (Kafka consumer lag, request queue depth). Database read replicas serve analytics queries without impacting transactional performance. Redis Cluster shards read projections by factory ID for predictable scaling as new factories are added. ## DevOps Pipeline GitHub Actions CI/CD with automated testing (unit, integration, E2E), security scanning (Snyk, Trivy), and infrastructure validation (Terraform plan). Blue-green deployment on Kubernetes with health check gating and automated rollback on metric degradation. Centralized logging with OpenTelemetry, Loki, and Grafana. Prometheus monitoring with custom alerts for business metrics (production order backlog, inventory stockout risk). ## Results Production planning cycle reduced from 3 days to 4 hours. Inventory accuracy improved from 72% to 99.2%. Financial close time reduced from 10 days to 2 days. Supplier lead time variability reduced by 35% through data-driven purchasing. Overall equipment effectiveness improved from 68% to 84% through real-time monitoring and predictive maintenance triggers. The system now handles 50,000+ daily production transactions across 3 factories. ## Lessons Learned Event-driven architectures introduce eventual consistency that requires careful UI design — we implemented optimistic UI updates with WebSocket reconciliation for real-time dashboards. CQRS adds complexity in command-validation-read flows but pays off in query performance at scale. Multi-factory deployment requires rigorous tenant isolation testing — a schema migration that succeeds in Factory A may fail in Factory B due to data differences.

View Case Study
Artificial Intelligence

AI Customer Service Platform — Intelligent Support Automation

An AI-powered customer service platform built for a telecommunications company handling 500,000+ monthly customer interactions across WhatsApp, email, live chat, and phone. The legacy system relied on 200+ human agents using scripted responses with an average first-response time of 45 minutes and a resolution rate of only 62% on first contact. ## Business Challenge The telecom provider faced escalating support costs as their subscriber base grew to 10 million. Customer satisfaction scores were declining due to long wait times and inconsistent answers. Agents spent 60% of their time answering repetitive questions — billing inquiries, plan changes, network coverage checks — rather than solving complex problems. The knowledge base existed as 50+ PDF documents that agents searched manually. Multichannel support (WhatsApp, email, chat, phone) operated in silos with no unified customer context. ## Solution Architecture We built an AI Customer Service Platform using a Retrieval-Augmented Generation architecture. The core components include a knowledge ingestion pipeline that converts documents into vector embeddings stored in Qdrant, a RAG-based AI engine that retrieves relevant knowledge and generates contextual responses using OpenAI GPT-4o via the Sumopod provider, a human handoff system that escalates to agents when AI confidence drops below threshold, a multi-channel gateway that unifies conversations from WhatsApp Business API, email, and web chat into a single thread, and an analytics engine tracking resolution rates, response times, and customer satisfaction. ### AI Pipeline Architecture Documents (PDFs, FAQs, product specs) flow through an ingestion pipeline: text extraction → chunking (512-token segments with 64-token overlap) → embedding generation (text-embedding-3-large) → vector storage in Qdrant with metadata filters. At query time, the user message is embedded and used for hybrid search (dense + sparse) against Qdrant. Top 5 chunks are retrieved and inserted into a prompt template that includes conversation history, retrieved context, and system instructions defining the AI as a professional support agent. The LLM generates a response with confidence scoring. If confidence < 0.7, the conversation is escalated to a human agent with full context. ## Key Features AI Chatbot powered by GPT-4o with RAG for accurate, context-aware responses trained on company-specific knowledge. Knowledge Base management with versioned articles, automatic re-indexing on updates, and content quality scoring. Intelligent ticketing with automatic categorization using fine-tuned classifiers and priority assignment based on sentiment analysis. Human escalation with full conversation context transfer — agents see the AI conversation history, retrieved knowledge, and suggested responses. Multichannel support unified across WhatsApp, email, live chat, and phone with consistent AI responses. Analytics dashboard tracking containment rate, resolution time, CSAT, agent productivity, and topic clustering. ## Technology Stack Frontend built with Next.js and React for the agent dashboard and admin console. Python backend with FastAPI for the AI orchestration layer handling embedding generation, vector search, and LLM integration. OpenAI API for GPT-4o models with prompt caching optimization. Qdrant vector database for high-performance similarity search with quantization for memory efficiency. PostgreSQL for transactional data — tickets, users, conversations, knowledge articles. Redis for caching frequent queries, session state, and rate limiting. Docker containers with Kubernetes orchestration for horizontal scaling of AI workers. ## Security Customer PII is filtered before reaching the LLM — phone numbers, email addresses, and account numbers are masked with placeholder tokens. All API communication uses TLS 1.3. Knowledge base access is role-restricted. Conversation logs are encrypted at rest with AES-256. The system maintains SOC 2 Type II compliance with audit logging of every AI interaction. ## Results First-response time reduced from 45 minutes to under 30 seconds. Resolution rate on first contact improved from 62% to 85%. AI containment rate reached 72% — nearly three-quarters of inquiries handled without human intervention. Agent headcount reduced from 200 to 80 while handling 2x conversation volume. Customer satisfaction increased from 3.2 to 4.6 out of 5. Monthly support cost reduced by 60%. ## Lessons Learned RAG quality depends critically on knowledge base curation — poorly structured documents produce poor retrieval results. Investing in knowledge architecture upfront (hierarchical taxonomy, consistent formatting, regular reviews) yields compounding returns. AI confidence thresholds need continuous tuning — set too high, excessive escalation defeats the purpose; set too low, incorrect AI responses damage trust. Multichannel unification is the unsung hero — customers switching channels mid-conversation was a major pain point solved by the unified thread architecture.

View Case Study
Start Your Project

Ready to build your enterprise solution?

Discuss your software engineering needs with the HattaDev engineering team.

Start the Conversation

Free consultation. No commitment.