apidays New York 2025 - Spring Modulith Design for Microservices by Renjith Ramachandran (BJS Wholesale Club)

Spring Modulith Design for Microservices
Renjith Ramachandran, Senior Solutions Architect at BJS Wholesale Club

apidays New York 2025
API Management for Surfing the Next Innovation Waves: GenAI and Open Banking
May 14 & 15, 2025

------

Check out our conferences at https://www.apidays.global/

Do you want to sponsor or talk at one of our conferences?
https://apidays.typeform.com/to/ILJeAaV8

Learn more on APIscene, the global media made by the community for the community:
https://www.apiscene.io

Explore the API ecosystem with the API Landscape:
https://apilandscape.apiscene.io/

Transcript

1. Spring Modulith Design for Microservices Renjith Ramachandran -Sr Solutions Architect,BJs Wholesale Club
2. Agenda • Monoliths to Microservices to Moduliths • Disadvantages of Monoliths & Microservices • Modulith Architecture • Designing the Modulith Architecture ◦ Defining the Module boundaries ◦ Intermodule Communications ◦ Securing the Modules ◦ Testing the Modules ◦ Design for DB Resilience ◦ Documentation,Code Maintenance, DevOps and Deployment ◦ Detaching a module as a Microservice • Spring Modulith • Disadvantages of Modulith Application • Questions
3. Monoliths to Microservices to Moduliths
4. Disadvantages of Monoliths & Microservices Monoliths • Tight coupling of logic within the monolithic application makes it difficult to implement changes • Testing becomes challenging as the application grows; especially unit and integration testing • Scaling a monolithic application is usually challenging; vertical scaling can be achieved, whereas horizontal scaling presents difficulties. • Adopting new versions of programming languages or new technologies can be challenging. Microservices • Data consistency between services becomes an issue. • Operational complexity increases with the number of services • Network overhead grows as services constantly communicate. • DevOps & Observability complexity increases with the number of services.
5. Modulith Architecture Modulith architecture acts as the middle ground between Monolith and Microservices architecture • Avoids distributed system complexities • Modules provide clear separation of concerns • Simplified testing • Less network complexity • Reduced operational and DevOps complexity • Easier to transition to Microservices • Aligns with Domain-Driven Design • Reduced complexity with Observability
6. Designing Modulith Architecture Defining the Modules Setting the Module boundaries Defining Intermodule Communications Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis sit amet odio vel purus bibendum luctus. Securing the Modules Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis sit amet odio vel purus bibendum luctus. Testing the Modules Lorem ipsum dolor sit amet, consectetur Documen. Duis sit amet odio vel purus bibendum luctus. Documenting the Modules Lorem ipsum dolor sit amet, consectetur
7. Defining Module and Module Boundaries Module Boundaries and shared assets Define Module Boundaries Define Ubiquitous language Define Shared assets Defining the Module Define Purpose of the Module Define Inputs and Outputs Define Functionalities Define Entities Define Owners Modular Architecture Defined Module with Purpose, Inputs & Outputs, Functionalities, Entities, Owners, Boundaries, and Shared Assets.
8. Intermodule Communications • Modules expose specific functionality that other modules can consume • Modules should be loosely coupled to facilitate easy decoupling into separate microservices. • Modules can communicate either synchronously (directly or through a connector) or asynchronously using an internal or external event bus
9. Securing the Modules • Modules will inherit the security settings of the containing application • Modules can implement additional security measures. ◦ Eg:A module may be configured to accept requests only from registered modules.
10. Testing the Modules • Modules should have their own independent unit test cases. • Integration test cases can cover scenarios involving multiple modules.
11. Design for DB Resilience One DB with set of tables for each module One DB with different schema for each module Different DB for each module
12. Documentation,Code Maintenance & DevOps, and Deployment • Documentation : Each module should provide documentation for developers to facilitate integration. Tools can be used to auto -generate this documentation. • Code Maintenance & DevOps: Code may be maintained by the same team or different teams. Modules can either be part of the same application or maintained as separate applications, exported as JAR files, and integrated into a WAR file during build time. • Deployment : The application, along with its modules, can be containerized, deployed, and scaled as needed.
13. Detaching a module as a Microservice • A module can be detached and converted into a separate microservice when it becomes a "hot module" in the following scenarios ◦ The module is heavily used by other applications, causing the entire application to require autoscaling due to the demands of a single module ◦ The application requires frequent updates primarily due to changes in one module.
14. Spring Modulith • New Approach within Spring Framework which brings in modular approach design principles to application. • GA Version was released in August 2023. Current stable version is 1.2.5. • Provides tooling and architecture support to build modulith application • Encourages bounded context where each module encapsulates specific business functionality . • Helps to define clear module boundaries • Supports direct and event driven (sync & async) communication between modules • Integrates seamlessly with other Spring tools and components like Spring Data, Spring Actuator , Spring Security etc. • Avoids cyclic dependencies and supports explicit dependencies. • Supports testing modules independently or along with other modules.
15. Disadvantages of Modulith Application • Maintaining modular boundaries can be challenging. • The entire application must be scaled if one module experiences high traffic. • Managing dependencies between modules can be complex. • Deciding when to detach a module as a separate service can be difficult. • A fatal error in one module can potentially bring down the entire application.
16. Q&A