Akash Ramesh Full Stack Software Engineer ← Back to portfolio

Customer Income Capture MicroserviceLive

Direct from customer income capture at credit card activation for an enterprise banking client. Cut data vendor costs 20% and lifted offer conversion 12%.

JavaSpring BootMongoDBApigee Jenkins CI/CDHadoop/HiveSQLKubernetes PCFAWS ECSLambda

What it is

A new microservice extending the client's core banking application to capture customer declared income directly at the point of credit card activation.

Previously, income data came from credit application forms, often 3 months or more out of date, or from third party income surveys that could take up to 6 months to return results.

This service adds a direct, first party data entry point at exactly the moment the customer is engaged, closing that gap.

Architecture

Customer Apigee Gateway Spring Boot Service MongoDB Hadoop/Hive Pipeline Enterprise Datalake Tableau

Customer declares income during card activation. Apigee handles auth and rate limiting before the request reaches Spring Boot. Income is written to MongoDB, then folded into the existing Hadoop/Hive batch pipeline via extended SQL queries. The same data reaches both the offer targeting system and business analyst Tableau dashboards.

Decisions

01

First party income capture at the activation moment

The existing process relied on stale credit application data, 3 months or more old, or expensive third party income surveys with a 6 month turnaround. The decision was to add a direct capture step at card activation, when the customer is already engaged and motivated to complete the process, rather than sending a separate survey later.

02

MongoDB as the transactional store

Income data at card activation is document shaped, not relational. Each activation event has a variable set of income fields depending on the customer's employment type. MongoDB was chosen as the transactional store to accommodate that variability without requiring schema migrations for each new income type.

03

Extending the existing Hadoop/Hive pipeline rather than building a new one

The existing Hadoop/Hive batch pipeline was extended with new SQL queries, instead of building a parallel data pipeline for the new income data. This kept the data flowing to the same enterprise datalake and Tableau dashboards the business already used, with no new tooling or analyst retraining required.

04

Apigee for gateway security rather than in service auth

Authentication, rate limiting, and routing were handled at the Apigee gateway layer rather than inside the Spring Boot service itself. This kept the microservice focused on business logic and meant security policy changes could be applied at the gateway without a service redeployment.

Outcomes

  • 61% customer adoption of the new income capture flow at card activation
  • 20% reduction in external data vendor costs, from fewer paid income surveys needed
  • 12% lift in targeted offer conversion in the initial release, from fresher first party income data feeding targeting models
  • Manual review time cut from 3 to 6 months down to real time
  • Extended existing Hadoop/Hive pipelines so captured income reached business analyst Tableau dashboards, not just the offer targeting system

Integration footprint

ServiceRoleAuth method
ApigeeAPI gateway, authentication, rate limiting, routingAPI key / OAuth policies
JenkinsCI/CD, automated build and deploymentInternal pipeline
MongoDBTransactional store for captured income dataInternal service credentials
Hadoop/HiveBatch pipeline feeding the enterprise datalakeInternal service credentials
KubernetesContainer orchestration for microservice deploymentInternal
AWS ECS/LambdaScalable workload hosting post PCF migrationIAM roles
TableauBusiness analyst dashboards consuming datalake dataInternal service credentials

Screenshots

Screenshots available on request This is a client project. Visual assets are shared during interviews and technical reviews.

Downloads

← Back to home