🧭 Series Navigation:
✅ Part 1: Architecture Overview (Current)
▶️ Part 2: Development Environment & Debugging
▶️ Part 3: Testing Strategies
▶️ Part 4: CI/CD Deployment with Jenkins
My AdventureTube Microservice Design Journey
The big picture I had when I created AdventureTube is that I wanted to build a fundamental foundation of skills that includes not only server-side or client-side development, but actually encompasses the whole ecosystem – from content producers (iOS application) to content consumers (Spring microservices). Eventually, this project can be used as a base platform for any other content-related applications.
So you looking at the backend system of AdventureTube, which is a Spring Cloud microservice architecture designed to handle complex content management and delivery tasks. This architecture is built on enterprise-grade design patterns that ensure scalability, maintainability, and robustness.
Additionally, Project is highly driven by Windsurf which is best coding companion as single man project. I am a strong believer that developing paradigms are shifting very quickly for all engineers, and it is inevitable that collaborating with AI will be the most critical factor to describe your job capabilities. This guide shares the architectural foundation I’ve developed that powers AdventureTube’s backend system, before I tackle into much detail of individual study case in developing blog.
Technical aspects of My Architecture of CMS and CRM
It functions primarily as a Content Management System (CMS) and partially as a Customer Relationship Management (CRM) system, processing user-generated content and storing it in two databases:
- RDBMS (PostgreSQL 15.2): Stores structured data such as user details and content metadata.
- MongoDB 6.0: Handles mapping user content and enabling location-based interactions.
The backend ensures secure storage, access control, and authentication using:
- Spring Boot 3.2 – Provides a modular and scalable microservices architecture.
- Spring Security 6.2 – Manages authentication, authorization, and access control.
- JWT (JSON Web Token) with RSA Encryption – Enables secure, stateless user authentication.
Using Spring Cloud components, the system achieves:
- Service Discovery: Eureka for dynamic service registration and discovery.
- Configuration Management: Config Server for centralized configuration management.
- API Gateway: Spring Cloud Gateway for routing and load balancing.
Making system more responsive and resilient with:
- WebFlux: Reactive programming model for non-blocking I/O operations.
- Event Streaming: Apache Kafka for real-time data processing and event-driven architecture.
Separation of Concerns with Three-Layer Architecture
With this tech stack, the entire backend system is organized into three distinct layers, which makes perfect sense for creating separate Docker Compose files for initialization and management. As you can expect, the first two sections – Infrastructure Layer and Platform Layer – are not subject to frequent development iteration, but rather serve as a stable foundation that I can rely on. The Business Layer is where I focus on developing and iterating my business logic, except in situations where there are major updates for infrastructure or platform levels.
Probably the gateway will be the only one along with security or authentication flow changes, even though these are still not as frequent as business logic changes.
🗄️ Infrastructure Layer (Storage Systems)
File: docker-compose-storages.yml
I use this layer for data persistence and storage systems
🌐 Platform Layer (Spring Cloud Applications)
File: docker-compose-clouds.yml
I use this layer to handle cross-cutting concerns and system-wide functionality
🔧 Business Layer (Domain Services)
File: docker-compose-adventuretubes.yml
I focus this layer on specific business capabilities and domain logic
As a consequence of this approach, this structure allows for independent scaling, deployment, and technology choices while maintaining clear boundaries between infrastructure, platform, and business concerns.
This was unexpected initially, but it provides me with great flexibility in managing the entire system, which actually allows me to use two separate Raspberry Pi 5 micro servers so that I don’t need to pay anything for cloud services during the development phase.
Service Introduction
🗄️ Storage Infrastructure Layer (docker-compose-storages.yml)
Lets skip this section for now, since it is more about the infrastructure and storage systems that maybe not a good subject as part of application architecture.
🌐 Platform Layer (docker-compose-clouds.yml)
Eureka Server (http://192.168.1.105:8761/)
Central service registry that handles automatic registration, health monitoring, and dynamic service discovery for all microservices.
Config Server (http://192.168.1.105:9297/)
Centralized configuration management system that provides environment-specific settings and Git-based version control for all services.
Gateway Service (http://192.168.1.105:8030/)
Single entry point API gateway that handles request routing, authentication, rate limiting, and Swagger documentation aggregation.
🔧 Business Layer (docker-compose-adventuretubes.yml)
Auth Service (http://192.168.1.112:8010/)
JWT-based authentication and authorization service with Google OAuth integration for secure user identity management.
Member Service (http://192.168.1.112:8070/)
User profile and account management service handling registration, preferences, and relationship data.
Geospatial Service (http://192.168.1.112:8060/)
Location-based service using MongoDB for spatial data and Kafka for fail-safe storage processing so it can handle high demand and real-time event streaming.
Web Service (http://192.168.1.112:8040/)
Frontend interface service that can be utilized by any other web application that need to merged with the AdventureTube content ecosystem, providing a user-friendly experience.
Build process for Business Layer Services
Why I pulled out Docker Compose for business layer services
So now we’ve touched the basic structure of the backend system and have a big picture of how the services are organized. Let’s take a look at how I build and run these services in my development environment, especially for the business layer services, which are the core of the AdventureTube content ecosystem. These require frequent development iterations that could potentially damage build performance if we use Docker Compose without properly reviewing its necessity – which actually happened during my first two weeks of development.
Docker takes time and resources to build and run services in containers, but these costs can be mitigated by the strong advantages of distributed systems – flexibility of resource assignment on demand and the ability to run services on multiple devices without worrying about underlying infrastructure. But what about the development process? Are the advantages of using Docker Compose actually necessary during development? This is the main reason I pulled out Docker Compose for business layer services them locally in my IDE (IntelliJ) to get the best performance during the development phase and run the tests locally in my IDE (IntelliJ) before trigger jenkins process after commit the source code to the github and apply those changes to PI2 server which is QA server at this moment
Initialization process of service modules
[Architecture Diagram 1 – Complete System Overview will be placed here]
The first diagram illustrates the complete three-layer architecture showing how infrastructure (storage systems), platform (Spring Cloud services), and business layer services interact within the AdventureTube ecosystem.
[Architecture Diagram 2 – Service Initialization Flow will be placed here]
The second diagram details the centralization and externalization concept that drives the initialization process. Here’s how each business layer service module starts up:
- Service Discovery Registration: Each service connects to Eureka Server (192.168.1.105:8761) for dynamic registration and health monitoring
- Configuration Loading: Services pull their environment-specific settings from Config Server (192.168.1.105:9297) using Git-based version control
- Gateway Integration: All services register their endpoints with Gateway Service (192.168.1.105:8030) for unified API routing
- Database Connection: Services establish connections to PostgreSQL (structured data) and MongoDB (spatial/content mapping) based on their specific needs
- Kafka Integration: Event-driven services connect to Apache Kafka for real-time data processing and fail-safe storage
This centralized approach ensures consistent initialization across all business services while maintaining the flexibility to run them locally during development for optimal performance and debugging capabilities.
What I’ll Show You Next
Now that I’ve explained my three-layer architecture and Docker Compose organization that forms the backend foundation of AdventureTube’s content ecosystem, you’re ready to see how I implement this in my development environment.
🧭 Continue Learning My Approach:
✅ Part 1: Architecture Overview (Current)
▶️ Part 2: Development Environment & Debugging – How I set up efficient development workflows with this architecture
▶️ Part 3: Testing Strategies – My comprehensive testing approaches across all three layers
▶️ Part 4: CI/CD Deployment – How I automate deployment of all Docker Compose layers
In Part 2, I’ll show you exactly how I set up my development environment to work efficiently with this backend system architecture, including my IntelliJ configuration, how I connect to the Docker infrastructure, and debugging strategies that enable rapid development of the content management platform.
Tags: #Microservices #SpringCloud #DockerCompose #Architecture #ThreeLayerArchitecture
Categories: BACKEND(spring-microservice), Architecture
Related Posts: