All case studies

FinTech · Personal Finance Platform

Hysab Kytab

A B2B/B2C personal finance platform used by digital banks, where a rounding error is a customer complaint and downtime is a headline.

Backend Architecture & Distributed SystemsVisit hysabkytab.com
100K+

Financial events per day

Across a three-broker Kafka cluster

5

Databases unified

PostgreSQL, MongoDB, MySQL, Oracle and SQL Server

60%+

Lower read latency

From a Redis cache-first strategy

One financial picture from many disagreeing sources

Hysab Kytab gives banking customers a single view of their money, covering balances, spending, categories and insights, aggregated across multiple banks. It is delivered to digital banking leaders including Temenos and Interswitch, which means it inherits their reliability expectations rather than a startup’s.

The core difficulty was consolidation. Every upstream source had its own database, its own format and its own idea of when data is correct: PostgreSQL, MongoDB, MySQL, Oracle and SQL Server all had to end up behind one coherent service layer without losing precision or slowing the app down.

I architected a distributed microservices ecosystem in Golang and NestJS, using Golang for the performance-critical core services and event-driven processing to keep aggregation off the request path entirely.

Stack

GolangNestJSSpring BootApache KafkaRabbitMQgRPCRedisPostgreSQLMongoDBOracleSQL ServerLangChainGCP
The problem

What made this hard

Disparate data sources

Five database engines and multiple bank feeds had to become one low-latency, consistent financial picture.

Precision under load

Financial data tolerates no drift, while still serving customer-facing apps at interactive speed.

Bank-grade availability

High availability and data integrity expectations set by enterprise banking clients, not by us.

System design

High-level architecture

A polyglot backend hidden behind one coherent service layer, so the banking app never has to know which engine an answer came from.

Client layer

B2B bank integrations and B2C apps

Digital bank appsTemenos · Interswitch
Consumer appPersonal finance
Admin & ops consoleWeb

Service layer

gRPC between services, REST at the edge

Aggregation servicesGolang
Transaction servicesGolang
Domain & product APIsNestJS
Enterprise servicesSpring Boot
AI advisory & insightsLangChain · RAG

Event & cache layer

100K+ financial events per day

Kafka cluster3 brokers · audit & alerting
RabbitMQRouted processing
RedisCache-first reads

Data layer

Five engines, one service contract

PostgreSQLCore relational
MongoDBFlexible documents
OracleBank systems
SQL ServerEnterprise integration
MySQLLegacy services
Architecture

From bank feed to financial insight

Aggregation is slow and unpredictable; customer apps are neither. The whole design separates those two realities so the slow half never blocks the fast half.

  1. 1

    Multi-bank aggregation

    Connectors pull account and transaction data from multiple banking sources, each with its own format and refresh cadence.

    GolangREST
  2. 2

    Encrypted ingest

    End-to-end encryption in Golang protects financial payloads in transit across service boundaries.

    GolangE2E encryption
  3. 3

    Kafka event backbone

    Over 100,000 financial events a day flow through a three-broker cluster feeding monitoring, audit trails and real-time alerting.

    Apache KafkaRabbitMQ
  4. 4

    gRPC service mesh

    NestJS, Golang and Spring Boot services communicate over gRPC, coordinated through Kafka and RabbitMQ.

    gRPCNestJSSpring Boot
  5. 5

    Multi-database persistence

    PostgreSQL, MongoDB, Oracle and SQL Server unified behind one cohesive service layer, each used where it is genuinely the right tool.

    PostgreSQLMongoDBOracleSQL Server
  6. 6

    AI expense intelligence

    LangChain RAG pipelines and a Shariah-compliant multi-agent advisory chatbot turn raw transactions into guidance.

    LangChainRAG
  7. 7

    Cache-first delivery

    A Redis cache-first read strategy cut average read latency by more than 60%, keeping the customer app responsive.

    Redis
Decisions

Why these tools, and not others

Core services

Golang

High-performance communication and predictable latency for the services on the critical financial path.

Event processing

Kafka + RabbitMQ

Kafka for the durable, replayable event backbone; RabbitMQ for targeted fan-out where routing matters more than retention.

Read performance

Redis cache-first

Aggregated financial views are read far more often than they change, making caching the highest-leverage optimisation available.

Persistence

Polyglot by design

Bank integrations dictated the engines; the service layer absorbed that complexity so product teams never had to.

Outcome

What it delivered

99.9% data integrity

Maintained across a five-engine database landscape serving financial applications.

60%+ latency reduction

A Redis cache-first strategy measurably improved the customer-facing experience.

25% lower cloud costs

GCP infrastructure optimisation and better observability, with no loss of reliability.

Trusted by digital banks

Delivered to global digital banking leaders including Temenos and Interswitch.

Scaling & availability

  • Event-driven aggregation keeps slow bank calls off the request path
  • gRPC between services for low-overhead internal communication
  • Three-broker Kafka cluster with consumer groups per domain
  • Redis cache-first reads for customer-facing views
  • Independently scalable services per banking integration

Security & reliability

  • End-to-end encryption implemented in Golang for financial payloads
  • Enforced REST and gRPC security standards across services
  • Audit trails built on the Kafka event log
  • Real-time monitoring and alerting on financial event streams

Building something like this?

If any of the problems above look familiar, I can help, whether that's a full architecture or a second opinion on the one you have.

Open to remote and hybrid work worldwide