This repository is dedicated to configuration management for the Travel Bank microservices application. It is designed to support scalable, cloud-native architecture using Spring Boot configuration best practices.
This repository continues from:
TRAVEL-BANK_Microservices_v.1.0TRAVEL-BANK_Docker_v.2.0
The current version, v3.0, focuses on centralized configuration management, making the services more maintainable and scalable.
Spring Boot supports multiple ways to read application properties. Here’s a breakdown of the most commonly used approaches:
Inject individual property values directly into Spring Beans.
@Value("${property.name}")
private String propertyValue;Use the Environment interface to programmatically fetch property values.
@Autowired
private Environment environment;
public void getProperty() {
String propertyValue = environment.getProperty("property.name");
}Bind groups of related properties to a POJO class.
@ConfigurationProperties(prefix = "prefix")
public class MyConfig {
private String property;
// getters and setters
}This avoids hardcoding keys and improves maintainability.
Spring provides a powerful tool called profiles to manage configuration for multiple environments like dev, qa, and prod. Profiles allow selective loading of properties and bean creation based on the environment.
application.properties→ Default profileapplication_qa.properties→ QA environmentapplication_prod.properties→ Production environment
spring.profiles.active=prodSpring Boot supports various methods to externalize configuration after the JAR is built:
java -jar accounts-service.jar --build.version="1.1"java -Dbuild.version="1.2" -jar accounts-service.jarWindows:
env:BUILD_VERSION="1.3"; java -jar accounts-service.jarLinux/macOS:
BUILD_VERSION="1.3" java -jar accounts-service.jarSpring handles relaxed binding (e.g., BUILD_VERSION becomes build.version).
- Risk of manual errors due to CLI/JVM arguments
- Difficult to track/audit config changes
- Lack of granular access control with environment variables
- Challenges in managing config in distributed setups
- No built-in encryption for secrets
- Config reload without restart requires additional tools (e.g., Spring Cloud Config)
Each microservice in the Travel Bank ecosystem is fully containerized using Docker.
docker compose up -d
docker compose down| Method | Command |
|---|---|
| Google Jib | mvn compile jib:dockerBuild |
| Buildpacks | mvn spring-boot:build-image |
| Dockerfile | docker build . -t : |
docker run -p 8080:8080 vinaysteja0231/accounts:v2.0
docker run -d -p 8080:8080 vinaysteja0231/accounts:v2.0A microservices-based banking platform built with Spring Boot.
| Service | Features |
|---|---|
| Accounts | Customer registration, account creation, validations, exception handling |
| Cards | Card issuance, CRUD for cards |
| Loans | Loan application, tracking, CRUD operations |
- Java 17+
- Spring Boot 3.x
- Spring Data JPA
- H2 Database
- Swagger (OpenAPI)
- Docker + Buildpacks + Jib
- Maven
- Postman
- 📘 Swagger UI: http://localhost:8080/swagger-ui/index.html
- 💾 H2 Console: http://localhost:8080/h2-console
A ready-to-use Postman collection is available here:
📂 File: TRAVEL-BANK.postman_collection.json
🔹 Test all microservices from one place
- 📡 Integrate Kafka for event-driven architecture
- 🧭 API Gateway + Eureka Discovery
- 📊 Logging & Monitoring with ELK Stack
- 🐳 Docker Compose for full service orchestration
travelbank-microservicestravelbank-docker
Feel free to fork, raise issues, or submit pull requests. Feedback and improvements are always welcome!
This project is licensed under the MIT License.