🧭 Series Navigation:
⬅️ Introduce AdventureTube Microservice Hub
✅ Part 1: Architecture Overview (Current)
▶️ Part 2: Development Environment & Debugging
▶️ Part 4: CI/CD Deployment with Jenkins
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
This foundational layer provides all data persistence and storage systems:
- PostgreSQL Database: Primary relational database for structured data, user profiles, and content metadata
- MongoDB Database: NoSQL database optimized for geospatial data and flexible content storage
- Redis Cache: In-memory caching for session management and performance optimization
- Storage Volumes: Persistent file storage for media content and system backups
🌐 Platform Layer (Spring Cloud Applications)
File: docker-compose-clouds.yml
This layer handles cross-cutting concerns and system-wide functionality:
Eureka Server
Central service registry that handles automatic registration, health monitoring, and dynamic service discovery for all microservices.
Config Server
Centralized configuration management system that provides environment-specific settings and Git-based version control for all services.
Gateway Service
Single entry point API gateway that handles request routing, authentication, rate limiting, and Swagger documentation aggregation.
🔧 Business Layer (Domain Services)
File: docker-compose-adventuretubes.yml
This layer focuses on specific business capabilities and domain logic:
Auth Service
JWT-based authentication and authorization service with Google OAuth integration for secure user identity management.
Member Service
User profile and account management service handling registration, preferences, and relationship data.
Geospatial Service
Location-based service using MongoDB for spatial data and Kafka for fail-safe storage processing to handle high demand and real-time event streaming.
Web Service
Frontend interface service that provides APIs for any web application needing integration with the AdventureTube content ecosystem.
Architectural Benefits
This structure allows for independent scaling, deployment, and technology choices while maintaining clear boundaries between infrastructure, platform, and business concerns. This approach provides great flexibility in managing the entire system, allowing the use of two separate Raspberry Pi 5 micro servers without paying for cloud services during the development phase.
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 during the development phase and run them locally in my IDE (IntelliJ) to get the best performance.
I run the tests locally in my IDE (IntelliJ) before triggering jenkins process after committing the source code to github and applying 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 for dynamic registration and health monitoring
- Configuration Loading: Services pull their environment-specific settings from Config Server using Git-based version control
- Gateway Integration: All services register their endpoints with Gateway Service 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:
⬅️ Introduce AdventureTube Microservice Hub
✅ 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:
- Spring Security and Authentication HUB
- Exception Handling in Microservices
- Backend Development Fundamentals