Java Engineering Lead

Rahul Gupta

Java Engineering Leader and Cloud Architect.

I modernize regulated banking platforms into event-driven, cloud-native systems, and lead the engineers who build them.

Java Engineering Lead
Cloud Architect
AI Builder

View Work Contact →

Engineering impact

Where I've operated

Platform Modernization

Problem

A monolithic system that needed to scale, evolve, and fail safely — without a rewrite that stopped the business.

Contribution

Led the modernization of a monolithic cash-management platform into an event-driven, cloud-native system — moving core services to Spring Boot on Azure App Service and Functions, decoupling them through Azure Event Hubs, and building a data pipeline through Data Factory into Databricks and a Lakehouse architecture.

Technologies

Spring Boot
Azure App Service
Azure Functions
Azure Event Hubs
Data Factory
Databricks
Lakehouse
Azure Front Door

Impact

Services that scale independently instead of together, failures that stay contained instead of cascading, and a system that can keep evolving without a monolith holding it back.

Distributed Systems

Problem

Balance and transaction data that clients needed combined into a single export, in whatever format their downstream systems expected.

Contribution

Designed a reporting gateway that combines balance and transaction data and exports it as PDF, CSV, Excel, NACHA, or BAI — using progressive data loading and asynchronous processing with server-sent events so large exports never block the system, backed by an active-active deployment and secure authorization on every request.

Technologies

Progressive Data Loading
Asynchronous Processing
Server-Sent Events
Active-Active Deployment
Secure Authorization

Impact

A single gateway that handles both small, instant exports and large, long-running ones — without either kind degrading the experience of the other.

Engineering Leadership

Problem

Regulated banking systems that don't get built by one team in isolation — decisions need buy-in across time zones and functions.

Contribution

Lead and mentor a team of six engineers, work with global engineering and business teams, and set architecture and engineering standards — not just for my own team's code but for how the platform is built going forward.

Technologies

Engineering Management
Architecture & Engineering Standards
Cross-Team Delivery

Impact

Regulated enterprise banking systems delivered where correctness and reliability aren't negotiable.

Applied AI

Problem

AI product ownership that goes beyond calling a hosted API from inside an enterprise system.

Contribution

Co-founder and builder of Future Readers, an AI-powered personalized children's storytelling platform — product, AI, and engineering — now in development with invitation-only access opening soon. I also run local AI infrastructure on an NVIDIA DGX Spark, experimenting with local coding models.

Technologies

Applied AI Product Development
Local LLM Infrastructure
NVIDIA DGX Spark

Impact

A hands-on way to stay close to how these systems actually work, not just the APIs built on top of them.

Work

Selected work

Generalized case study. Architecture, terminology, and outcomes are illustrative and do not represent any employer's actual systems, client data, or proprietary implementation.

Modernizing a Cash-Management Platform

Client
API Layer
Event Hub
Services
Data Lakehouse

Context

A monolithic cash-management platform needed to become something that could scale, evolve, and fail safely — without a rewrite that stopped the business.

Challenge

The platform had to keep running throughout. In a regulated banking environment, a full rewrite that took the system offline wasn't an option, and every change had to preserve correctness while coordinating across global engineering and business teams.

Rahul's Role

Led engineering, architecture, and team delivery for the modernization program — setting the technical direction, leading a team of six engineers, and working with global engineering and business teams to keep the platform reliable throughout.

Architectural Decision

The core decision was to decouple services through an event backbone (Azure Event Hubs) instead of direct synchronous calls between them. Producers publish events; consumers process them independently, on their own schedule.

Tradeoffs

Event-driven decoupling trades immediate consistency for resilience — services have to be designed around eventual consistency and idempotent event handling, which is more to design and reason about than a direct synchronous call. The payoff: if one service falls behind or fails, it catches up from the event stream instead of taking the rest of the platform down with it.

Technologies

Spring Boot
Azure App Service
Azure Functions
Azure Event Hubs
Data Factory
Databricks
Lakehouse
PostgreSQL
Redis
Azure Front Door

Outcome

Services that scale independently instead of together, failures that stay contained instead of cascading, and a system that can keep evolving without a monolith holding it back.

What Rahul Learned

Modernizing a live, regulated system is as much about sequencing and risk as it is about the end-state design — what gets decoupled first, and how much of the old and new run side by side, matters as much as the target architecture itself.

Generalized case study. Architecture, terminology, and outcomes are illustrative and do not represent any employer's actual systems, client data, or proprietary implementation.

A Reporting Gateway for Balance and Transaction Data

Client Request
Reporting Gateway
Balance + Transaction Data
Formatted Export

Context

Clients needed balance and transaction data combined into a single export — in whatever format their downstream systems expected.

Challenge

Export requests ranged from a single small file to large, multi-format jobs, and the data itself was sensitive financial information. The gateway had to handle the smallest and largest requests equally well, without one degrading the other, and without loosening authorization on any request.

Rahul's Role

Designed the gateway's architecture end-to-end — the export pipeline, the asynchronous processing model, and the approach to availability and authorization.

Architectural Decision

Chose asynchronous, progressively-loaded processing with server-sent events for progress, instead of a synchronous request/response model — so a large export doesn't block the system or time out the client while it's being built.

Tradeoffs

Progressive, async delivery is more moving parts than a simple synchronous download — the client has to track a longer-lived request and its progress instead of just waiting on a response. Running active-active across regions for availability adds its own operational complexity, in exchange for the gateway staying up through a regional failure.

Technologies

Progressive Data Loading
Asynchronous Processing
Server-Sent Events
Active-Active Deployment
Secure Authorization

Outcome

A single gateway that handles both small, instant exports and large, long-running ones — without either kind degrading the experience of the other.

What Rahul Learned

Building for the smallest and largest request at once showed how much of large-scale system design is really about not letting the rare, expensive case degrade the common, cheap one — the two have to be designed together, not bolted on separately.

Architecture

How a request moves through the system

Eight stages a request passes through, top to bottom. Click any stage to see what it does and why it's built that way — or play the full flow.

Representative reference architecture — illustrative, generalized from patterns I've worked with. Not a reproduction of any employer's actual system.

01Client
Where a request starts — a browser, mobile app, or partner system calling in.
WhyEvery request begins here, before anything about trust, routing, or scale has been decided yet.
02Azure Front Door
The global front door for every request — it picks the closest healthy entry point and handles TLS before traffic reaches any application code.
WhyPutting routing, failover, and TLS termination at a managed edge means no individual service has to reimplement it, and the platform can fail over without anyone touching application code.
03API / BFF
Shapes each request for whoever's calling — a mobile app and a partner integration don't need the same response.
WhyA backend-for-frontend layer keeps client-specific formatting and authentication out of the core services, so those services stay focused on business logic.
04Spring Boot services
Where the business logic actually runs, built as event-driven microservices instead of one large application.
WhySmaller, focused services are easier to reason about, test, and change independently — the same reason a monolith gets harder to work with as it grows.
05Event Hub
The backbone that decouples services — one publishes an event, others pick it up and process it on their own schedule.
WhyDecoupling through events lets services scale and recover independently. If one falls behind, it catches up from the stream instead of taking the rest of the system down with it.
06Redis
A fast cache in front of the database, so the data requested most often doesn't need a round trip to storage every time.
WhyCaching absorbs read pressure that would otherwise hit PostgreSQL directly — which matters most exactly when the system is busiest.
07PostgreSQL
The system of record — where the durable, consistent state of the platform actually lives.
WhyTransactional consistency has to live somewhere solid; the cache and the event backbone exist to protect this from unnecessary load, not replace it.
08Data and analytics systems
Where transactional data lands for reporting and analytics, through a pipeline into a Lakehouse architecture.
WhySeparating the analytical workload from the transactional one means heavy reporting queries never compete with — or slow down — the live system.

Leadership

How I Lead

15+

Years of experience

40+

Engineers led and mentored, on a regulated banking platform

Leading engineers

I lead and mentor a team of six engineers building a regulated cash-management platform — responsible for both the people and the technical direction of what they build.

Technical direction

I set architecture and engineering standards — not just for my own team's code, but for how the platform is built going forward. In practice, that includes decisions like moving a monolith to an event-driven backbone: made and owned, not just recommended.

Mentoring

Mentoring six engineers is part of the same role as leading them — not a separate program, just the day-to-day of technical leadership.

Architecture reviews

Architecture reviews have been part of how I ship since early in my career — leading architecture, design, and backend delivery for a prepaid-card platform, with automated testing and formal architecture reviews built into delivery, not bolted on after.

Cross-functional alignment

Regulated banking systems don't get built by one team in isolation. I work with global engineering and business teams where decisions need buy-in across time zones and functions — the same kind of coordination that, earlier in my career, meant delivery across onshore and offshore teams on a single platform.

Delivery ownership

I deliver regulated enterprise banking systems, where correctness and reliability aren't negotiable — from leading a cash-management modernization program today, back through designing a reporting gateway end-to-end and leading backend delivery on a prepaid-card platform before that.

Balancing business risk and engineering quality

A modernization that can't take the business offline forces the tradeoff into the open: event-driven decoupling bought resilience and independent scaling at the cost of eventual consistency and more complex event handling — a cost worth paying only because the alternative was a fragile monolith no one could safely change.

Building in Public

Beyond Enterprise Engineering.

Outside of platform work, I build AI products end-to-end and keep learning hands-on — across AI, cloud, and software architecture.

Future Readers

An AI-powered personalized children's storytelling platform. I'm the co-founder and builder — product, AI, and engineering. It's in development now, with invitation-only access opening soon.

Local AI

I run local AI infrastructure on an NVIDIA DGX Spark and experiment with local coding models — a hands-on way to stay close to how these systems actually work, not just the APIs built on top of them.