Internet Banking Concept Microservices: a Spring Boot teaching deployment on Docker

A course project that happens to be a whole banking platform

This source code was developed for a Java based microservices tutorial series on javatodev.com, and the README is explicit about the intent. The author explains that the plan is to use an internet banking API concept with Spring Boot based microservices architecture, developing the core API first and letting it evolve into a full fledged REST API collection until deployments.

That framing matters for how you read the code. The domain is deliberately recognisable, with users, accounts, transfers and utility payments, because a banking domain gives the tutorial a set of services that obviously need to be separate. The user service handles registrations and retrieval, the fund transfer service handles transfers between accounts, the payment service processes utility payments, and the core banking service acts as a dummy banking core with accounts, users, transaction details and processors for banking transactions.

Two of those services are worth singling out. The user service does not implement its own user store; it consumes the Keycloak REST API to register and manage the user base, while also using a local PostgreSQL database. And the fund transfer service pushes messages to a centralised RabbitMQ queue for use by the notification service, which is the asynchronous part of the architecture and the reason the queue is in the stack at all.

The notification service is registered under the service registry and consumes all the messages from RabbitMQ to push notifications to end users, and the README marks it as PENDING Development. That single word tells you the async half of the design is described but not finished, which is the first thing to check if you are following the RabbitMQ part of the series.

Getting it running is three commands

The installation is a clone, a directory change and a compose up, and the README is explicit that the compose file is where you should run it from:

$ git clone https://github.com/JavatoDev-com/internet-banking-concept-microservices.git

$ cd internet-banking-concept-microservices/docker-compose

$ docker-compose up -d

The reason the third command runs from inside the docker-compose folder is that the compose file expects a relative path to the project, which is the kind of detail that costs people an hour when it is not stated. The -d flag puts it in the background, so the next step is to wait for the stack to come up rather than to watch the logs.

The container table in the README is the map of what you get, and it lists the fixed IP address and port mapping for each of the eleven containers. The openzipkin_server is at 172.25.0.12 on 9411 for tracing, the keycloak_web is at 172.25.0.11 on 8080, the keycloak_postgre_db at 172.25.0.10 with its 5432 port closed, and the mysql_javatodev_app at 172.25.0.9 on 3306. Then come the application containers in dependency order: the config server on 8090, the service registry on 8081, the API gateway on 8082, the user service on 8083, the fund transfer service on 8084, the utility payment service on 8085, and the core banking service on 8092.

The MySQL port being published on 3306 is the one thing to be careful about on a shared machine, and the Keycloak database port is deliberately closed.

The stack is the standard Spring Cloud set, and the version jump is large

The technology stack list in the README is worth reading as a shopping list for a Spring Cloud learning project, because it names seventeen items.

Java 21, Spring Boot 3.2.4 and Spring Cloud 2023.0.0 are the base. On top of that come the Netflix Eureka service registry and the Netflix Eureka service client, the Spring Cloud API Gateway, the Spring Cloud Config Server, Zipkin and Spring Cloud Sleuth for tracing, Open Feign for service to service calls, RabbitMQ for messaging, Prometheus for metrics, MySQL and Keycloak for persistence and identity, Docker and Docker Compose for running it, and Kubernetes.

Keycloak appears twice in the list, once among the persistence and identity items and once at the end, which is a small sign of the list being assembled over time rather than written once.

The release history explains the version jump. Release 1.0.0 was the initial release with Java 11 and Spring Boot 2, and release 2.0.0 is the updated version with Java 21, Spring Boot 3.2.4 and Spring Cloud 2023.0.0. So the project crossed two major Spring Boot generations and two major Java versions between its two tags, which means the two releases are not compatible with each other and the tutorial articles are probably split between them.

The tags are also a day apart, v.1.0.0 on 2024-05-14 and v.2.0.0 on 2024-05-15, and the last push was on 2026-07-27, so there is work on the branch well after the last release.

Testing the API needs a Postman collection and a seeded Keycloak

The README explains how to exercise the API, and the answer is a Postman collection plus pre-seeded data.

A whole suite related Postman collection can be synced from a shared URL, and the instruction is to clone it and switch to the LOCAL_DOCKER_SETUP environment. The collection is organised into named folders, and the instruction for testing is to proceed with the AUTHENTICATION API request under the BANKING_CORE_MICROSERVICES collection.

The data is already there. By default the project has dummy account details with user details under the core banking database, and the Keycloak instance is deployed with a default dataset matched to the application, including the client and user data sets for the identity setup. The test credentials are published in the README as [email protected] with the password 5V7huE3G86uB.

That is convenient for a tutorial and it is exactly what you would not want in a real deployment, so it is worth being clear about the difference. Here, an identity provider is seeded with a known admin account, a demo client and a populated identity partition, and a banking database ships with balance records. In a system handling real money, the same convenience would be a vulnerability.

The folder structure in the repository mirrors the services. There is a core-banking-service/ directory, an internet-banking-api-gateway/, an internet-banking-config-server/, an internet-banking-fund-transfer-service/, an internet-banking-service-registry/, an internet-banking-user-service/ and an internet-banking-utility-payment-service/, plus the docker-compose/ directory, a postman_collection/ directory, a draw_io/ directory for the architecture diagram, and an ai-dlc/ directory.

The tutorial series is the actual product

The README lists eleven articles, and reading the list tells you what the project is for and what order to learn it in.

The first is the free course with a practical project, which is this repository. Then service registration and discovery with Spring Cloud Netflix Eureka, setting up the API gateway with Spring Cloud Gateway, and authentication and authorization with Keycloak. After the infrastructure come the domain services in order: the core banking service, the user service, the fund transfer service and the utility payment service. The last three articles cover the cross-cutting concerns: communication with Spring Cloud OpenFeign, exception handling, and centralised configurations with Spring Cloud Config.

That ordering is a curriculum design, and it is the main reason to look at this project at all. Each service is introduced in an article that builds it step by step, and the repository holds the result. Reading the code of a service that you have just read an article about is a different experience from reading a finished codebase, because the article tells you which decisions were deliberate.

The architecture diagram lives in the draw_io/ directory, and the README links the project architecture image, so the visual model is available as an editable file rather than only as a picture.

The project is MIT licensed, the primary language is Java, and the author is Chinthaka Dinadasa, described as a Java fullstack developer from Sri Lanka and the author of JavatoDev.com.

How this compares to a smaller tutorial service

The alternative to this project is one of the many single service Spring Boot tutorials, and the difference in approach is about how much of the platform you inherit along with the lesson.

A single service tutorial teaches one thing well. It has one application, one database, no configuration server, no service discovery, and no message broker, so every hour you spend is spent on the subject. It is also something you can read in an afternoon and delete afterwards without losing anything.

This project gives you all of the platform in one command. That means a Eureka registry, a config server, a gateway, Keycloak with a seeded identity partition, Zipkin, a MySQL instance and a RabbitMQ broker are all running before you write a line of business logic, which is a realistic production topology and a lot of moving parts. The value is that you learn how those parts actually behave together, including the unglamorous parts, like which container has to be up before which, and what a request looks like as it passes through the gateway, through a Feign client, into a service and onto the queue.

The cost is the same in reverse. Most of the code in any given service is configuration, and the entry point into the system is the API gateway on 8082 rather than the service you came to read. There is also the fact that you are reading a project mid-course: the notification service is unfinished, and the releases show the codebase has been through two framework generation changes.

The sensible way to use it is as a lab. Run the whole stack, point the Postman collection at it, and change one thing at a time while reading the matching article.

Editorial conclusion

Adopt this project if you are learning Spring Boot microservices and want a complete, runnable banking domain to experiment on rather than a set of isolated snippets. Do not adopt it as a foundation for a real banking system, because the core banking service is described as a dummy, the notification service is still marked as pending, and the database credentials and test account are published in the README. Before you run it, note that the release tags move as a pair with the tutorial series, that 1.0.0 used Java 11 and Spring Boot 2 while 2.0.0 moved to Java 21 and Spring Boot 3.2.4, and that the Keycloak and MySQL containers in the compose file come with pre-seeded data.

Frequently asked questions

Official sources

1. JavatoDev-com/internet-banking-concept-microservices on GitHub
2. License: MIT
3. Project website
4. README
5. Releases