Transaction Management in Monolithic Architecture
In this article, we are going to learn Monolithic Architecture and Transaction Management when designing any software architecture for our projects.
By this article, we are going to learn how to perform transactions between Modules in Modular Monolithic Architecture and Design our E-Commerce application with Modular Monolithic Architecture.
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
Architecture Design Journey
There are many approaches and patterns that evolved over decades of software development, and all have their own benefits and challenges.
In the last article, we have learned and designed e-commerce application with Modular Monolithic Architecture style. Now we will focus on Vertical Considerations of Monolithic Application that you can see it the picture above. There are several vertical consideration that we are going to discuss:
- Communications
- Transaction Management
- Deployments
We are still in monolithic architecture and vertically we will learn
- How to communicate each other
- How to perform distributed transactions
- How to deploy on cluster
Transaction Management of Monolithic Architecture
In a monolithic architecture, transaction management is typically handled within a single, unified database. A transaction refers to a series of operations that are executed together as a single unit of work.
Transaction management in Monolith architecture is quite easy compared to Microservice Architecture. Many frameworks or languages contains some mechanism for transaction management. For example ORM tools with applying unit of work patterns.
The database provides a mechanism for ensuring that transactions are executed in an all-or-nothing fashion, meaning that either all of the operations in the transaction are successfully completed, or none of them are. This is accomplished through the use of database transactions, which ensure that if one operation in a transaction fails, the entire transaction is rolled back to its previous state, effectively undoing any changes that were made.
These mechanism have a single database of the whole application. They are developed for scenarios where all transactions are running on a single context. In other words, we can simply commit and rollback operations with these mechanism in monolith architectures.
Lets think about our e-commerce domain, We have transactional use case when placing order. You can see pseudo code for place_order method at image above. As you can see that we can handle all operations into one method and surround operation in a transactional scope.
By this way, Transactions operated in the transaction scope are kept in memory without writing to the database until they are committed, and if a Rollback is made at any time, all transactions that have been processed so far in the scope are deleted from memory and the transaction is canceled. Without rollback, when Commit is written to the database, the transaction is completed successfully.
In a monolithic architecture, because all of the application components are deployed together on the same server, there is no need for distributed transaction management. Instead, the application can make use of the transaction management capabilities provided by the database.
However, there are some potential downsides to relying on a single, unified database for transaction management in a monolithic architecture. As the application grows and becomes more complex, it may become harder to manage transactions effectively, and there may be issues with performance and scalability as the volume of transactions increases.
To address these issues, some organizations are moving towards more distributed architectures, such as microservices, which allow for more granular transaction management and greater scalability. However, it’s important to note that distributed transaction management can be more complex and require additional tools and protocols to ensure that transactions are executed correctly across multiple services.
Design Modular Monolithic Architecture — E-Commerce App
If we design e-commerce application with Modular Monolithic architecture, you can see the image below:
According to architecture, we can encapsulate new feature developments into a module. And every module can implement its own architecture like Layered, Onion, Clean and so on.
Design Microservice Architecture — E-Commerce App
If we design e-commerce application with Microservice architecture, you can see the image below:
Product microservice can use NoSQL document database Shopping Cart microservice can use NoSQL key-value pair database and Order microservice can use Relational database as per microservice data storage requirements.
What’s Next ?
- Microservices Killer: Modular Monolithic Architecture
- Macro-services to Nano-services: Evolution of Software Architecture
- Microservices Architecture: Problems and Solutions with Pattern and Principles
Step by Step Design Architectures w/ Course
I have just published a new course — Design Microservices Architecture with Patterns & Principles.
In this course, we’re going to learn how to Design Microservices Architecture with using Design Patterns, Principles and the Best Practices. We will start with designing Monolithic to Event-Driven Microservices step by step and together using the right architecture design patterns and techniques.
