The problem

This internal proof of concept explored moving a small banking use case out of a monolithic application into independently deployable services. It was my first professional engineering experience.

My role

I worked within a team delivery environment as a Program Trainee Analyst / Full Stack Developer. The work covered Java service implementation, databases, testing, deployment and monitoring; it was not a live client-system migration.

Architecture / Cognizant

An internal migration proof of concept

A bounded internal proof of concept: decompose, deploy, test and observe.

Request / data flowEvent / ingestion flowControl / fallbackSwipe to explore →
An internal migration proof of conceptA bounded internal proof of concept: decompose, deploy, test and observe. Java banking monolith: Small internal use case; Baseline response time: 1.2 s. Service boundary 1: Spring Boot / MVC; REST interface. Service boundary 2: Spring Boot / MVC; REST interface. Service boundary 3: Spring Boot / MVC; REST interface. Service boundary 4: Spring Boot / MVC; REST interface. H2 / MySQL persistence: Logical view; database topology unspecified. AWS deployment: EC2 · Elastic Beanstalk · S3; Independently deployed services. CloudWatch: Performance monitoring; Automated alerts. Testing: Unit · regression · white / black box; 85% code coverage. Measured proof-of-concept response: 1.2 s → 700 ms. Service names and unconfirmed infrastructure details are intentionally abstracted01 / DECOMPOSITIONFour service boundaries within a banking proof of concept02 / DELIVERY & VERIFICATIONCloud deployment and testing were part of the learning exerciseJava banking monolithSmall internal use caseBaseline response time: 1.2 sINTERNAL POCService boundary 1Spring Boot / MVCREST interfaceService boundary 2Spring Boot / MVCREST interfaceService boundary 3Spring Boot / MVCREST interfaceService boundary 4Spring Boot / MVCREST interfaceH2 / MySQL persistenceLogical view; database topology unspecifiedAWS deploymentEC2 · Elastic Beanstalk · S3Independently deployed servicesCloudWatchPerformance monitoringAutomated alertsTestingUnit · regression · white / black box85% code coverageMeasured proof-of-concept response: 1.2 s → 700 msService names and unconfirmed infrastructure details are intentionally abstracted
Conceptual decomposition and operational flow. Individual service names are omitted because they have not been confirmed. This represents an internal proof of concept.
Read the architecture as text

A bounded internal proof of concept: decompose, deploy, test and observe.

  • Java banking monolith: Small internal use case. Baseline response time: 1.2 s.
  • Service boundary 1: Spring Boot / MVC. REST interface.
  • Service boundary 2: Spring Boot / MVC. REST interface.
  • Service boundary 3: Spring Boot / MVC. REST interface.
  • Service boundary 4: Spring Boot / MVC. REST interface.
  • H2 / MySQL persistence: Logical view; database topology unspecified.
  • AWS deployment: EC2 · Elastic Beanstalk · S3. Independently deployed services.
  • CloudWatch: Performance monitoring. Automated alerts.
  • Testing: Unit · regression · white / black box. 85% code coverage.

Measured proof-of-concept response: 1.2 s → 700 ms

Service names and unconfirmed infrastructure details are intentionally abstracted

Split the use case into four services

I helped decompose the Java application into four Spring Boot microservices, using Spring MVC and H2/MySQL persistence. The proof of concept reduced response time from 1.2 seconds to 700 ms.

The exercise provided hands-on experience with service boundaries, interfaces and the operational work required when functionality is split across processes.

Test and observe the result

Unit tests, regression testing, and white-box and black-box testing brought code coverage to 85%. Testing was part of evaluating the migration rather than a separate afterthought.

I deployed services using AWS infrastructure including EC2, S3 and Elastic Beanstalk, and configured CloudWatch monitoring and automated alerts. The emphasis was learning disciplined implementation and operational practices in a corporate environment.

Outcomes

  • Reduced response time from 1.2 seconds to 700 ms in an internal banking proof of concept by helping decompose a Java monolith into four Spring Boot microservices.
  • Achieved 85% code coverage in the proof of concept by writing unit tests and carrying out regression, white-box and black-box testing.
  • Enabled independent deployment and operational monitoring of four services by deploying them on AWS and configuring CloudWatch monitoring and automated alerts.

Tradeoffs

Four services can be deployed independently, but they also introduce more interfaces and operational moving parts. The proof of concept was a bounded way to learn those tradeoffs before treating service decomposition as an automatic improvement.

Tools and technologies

JavaSpring BootSpring MVCH2MySQLAWS EC2S3Elastic BeanstalkCloudWatch

Related work