Analysis of Monolithic and Distributed Systems – Learn System Design

System analysis is the process of gathering the requirements of the system prior to the designing system in order to study the design of our system better so as to decompose the components to work efficiently so that they interact better which is very crucial for our systems.

System design is a systematic process involving phases such as planning, analysis, designing, deploying, and testing phases. Now the firstmost question would be why do analyze the system when we are well versed in the designing of systems. 

Analysis of Monolithic and Distributed Systems – Learn System Design

Difference between System Design and System Analysis 

Types of Systems in System Analysis and Design

Now that we have understood what is System Analysis and how System Analysis is different from System Design, it is now imperitive that we analyze the types of systems in System Design. Generally, the systems can be categorised into two broad categories:

1. Monolithic Systems
2. Distributed Systems built with help of Microservices

Now let us see about these types one by one in detail.

Monolithic Systems

If all the functionalities of a project exist in a single codebase, then that application is known as a monolithic application. 

As the name suggests monolithic means a formation with large single blocks only.  Henceforth with monolithic systems, we refer to a system where the whole web application is deployed as a single unit. Here all components and functionality are deployed in a single unit.

Monolithic Systems

Architecture of Monolithic systems

The Monolithic system architecture can be visualized by considering three sections or three layers:

1. Client Tier or User Layer or Presentation Layer: It is the closest layer to the user and hence it can be either a webpage or a web application where the user gets things done. It takes input lead from the user, interacts with the server, and displays the user result. Hence we call it a front-end layer.
2. Middle Tier or Service Layer: It compromises all the logic behind the application and is there in the application server. The application server includes the business logic, receives requests from the client, acts on them, and correspondingly stores the data.
3. Data Tier or Persistence Layer: It includes a data persistence mechanism(DB) and communication with other applications. It includes databases, message queues, etc. Database server will be used by application server for the persistence of data.              

Architecture of Monolithic systems

Synonym for Monolithic System

Monolithic systems are also known as Stubborn systems or Inflexible systems, as everything is depicted as a single unit.

Benefits of Monolithic Architecture

1. Easy development: It is simply a traditional model and does not require hardcore developers to develop such a design because it can never be complex.  
2. Easy deployment: As seen above all components are stored in a single block/repository so we just need to take care of that single repository while deploying.
3. Easy testing: Because of closed encapsulation end to end testing via tools is pretty easy.   

Why use Monolithic Architecture – Benefits of Monolithic Architecture

Tip: It is generally been used by organisation in start because of very less cross cutting issues. These issues affect the whole system as good developers know it such as caching, lodging and handling. It is confined in a single window so it becomes very easy to handle as seen above henceforth better handlability.  

Disadvantages of Monolithic Architecture

1. The codebase is stored in a single repository leading to difficulty in understanding. 
2. Any changes in the codebase (updation) will require complete redeployment of the software application. 
3. Less reusable.
4. Less scalable because each element will be having different scalability requirements. 

Tip: Also, it is challenging to introduce a change or replacement of the framework since every element is tightly encapsulated. 

Microservices

Microservices is an architectural development style in which the application is made up of smaller services that handle a small portion of the functionality and data by communicating with each other directly using lightweight protocols like HTTP. According to Sam Newman, “Microservices are the small services that work together.” 

Microservices

Microservices Architecture

The Microservice architecture has a significant impact on the relationship between the application and the database. 

• Instead of sharing a single database with other microservices, each microservice has its own database. 
• It often results in duplication of some data, but having a database per microservice is essential if you want to benefit from this architecture, as it ensures loose coupling. 
• Another advantage of having a separate database per microservice is that each microservice can use the type of database best suited for its needs. 
• Each service offers a secure module boundary so that different services can be written in different programming languages. 
• There are many patterns involved in microservice architecture like service discovery & registry, caching, API gateway & communication, observability, security, etc.

Microservices Architecture

Advantages

• Scalability: Microservices architecture allows individual services to scale independently of each other, which helps in optimizing resource utilization and reducing infrastructure costs.
• Flexibility: Since each service is a separate component, it can be developed, deployed, and updated independently of the others. This provides greater flexibility to the development team, allowing them to work on different parts of the application simultaneously.
• Resilience: In case of failure of one service, other services can continue to operate without interruption, making the system more resilient.
• Technology Heterogeneity: Microservices architecture allows for the use of different technologies and programming languages for different services, as long as they can communicate with each other.
• Easy maintenance: As each service is independent, it is easier to maintain and update the system without affecting other services.

Disadvantages

• Complexity: Microservices architecture involves the creation of a large number of small services, which can result in increased complexity in terms of development, deployment, and maintenance.
• Increased overhead: Since each service is a separate component, there is an increased overhead in terms of network communication and data consistency.
• Testing complexity: With multiple independent services, testing can become more complex, and there is a need to ensure that all services work together seamlessly.
• Distributed systems: Microservices architecture creates a distributed system, which can lead to additional challenges in terms of monitoring and management.
• Skillset: Developing microservices requires a different skill set than traditional monolithic application development, which can be a challenge for some development teams.

Monolithic vs Microservices architecture

For details on how Microservice Architecture is different from Monolithic architecture, please refer Monolithic vs Microservices architecture.

Monolith vs Microservices – Types of Systems in System Analysis and Design

Distributed Systems vs Microservices

If you are incorporating Microservices architecture or migrating from Monolithic to Microservices architecture, you cannot do all work on a single system (as it is against the modular feature of Microservices). This is where Distributed Systems were developed. 

Distributed Systems not only provide modularity to architecture but also gives you the advantage to use Microservice architecture easily to utilize all its benefits.

Now let us see what are Distributed Systems in depth.

Distributed Systems

A distributive system is a collection of multiple individual systems connected through a network sharing resources so as to achieve common goals. 

It is more likely seen in the real world as it has huge advantages over monolithic architecture making it highly scalable and at the same time with multiple systems sharing the same resource solves our SPOF problem. (Single Point Of Failure)

Distributed Systems Architecture

As seen above media, in a distributive system, nodes are geographically distributed. So what if a node crashes due to power failure? In Distributed systems, the data will not be lost as data has been shared across multiple servers. Hence redundancy/replication helps us in saving data which is very essential as a backup is already there to take over justifying SPOF. 

Example: Telecommunication Networks

Telecommunication Networks

Now let us discuss some merits and demerits of distributive systems:

Advantages of Distributed Systems

1. Scalable: As it contains a collection of independent machines horizontal scaling can be done to achieve scalability.  
2. Reliable: The distributed system solves SPOF while the monolithic does not because even if an individual unit fails to work rest are operational making it more efficient to work most of the time and hence reliable. 
3. Low latency: Because of multiple servers and more likely spread to get closer to the user to resolve a query, hence takes very less time to resolve a user query. 

Disadvantages of Distributed Systems

1. Complexity: Because of high scalability the number of network points and hardware makes the system quite complex and challenging. 
2. Consistency: Higher number of devices makes it difficult to integrate the data as it gets complex to synchronous application states. 
3. Network Failure:  Communication and coordination between systems in distributed systems is carried via network calls. In a network failure, conflicting information is passed or sometimes communication failure occurs leading to poor overall system performance.   

Note: Management is also a disadvantage here out because of load balancing functionality(It is a process of distributing the load to the nodes), logging, caching and monitoing is required to manage the systemto prevent failures. 

Race Conditions in Monolithic and Distributed Systems

Race condition is a bug that arises in systems due to timing mismatch of the execution order of multiple system services which leads to a degree of level of parallelism. 

We do see this condition in operating systems where we have encountered a deadlock state. Similarly, such conditions arise when we are scaling systems because of the collapse/overlapping of processes at a single moment.

Race Conditions in Monolithic and Distributed Systems

For Example let us consider the Banking system design gateway

We do a set of microservices that are functionally dependent and have interwind validation logic. Suppose ‘Credit cards services’  are issued to users those are having good CIBIL scores and vice-versa. In any system design, a request is placed through API calls for approval/disapproval of the same request. Now there are billion of users so the same number of calls are supposed to be made. Now in distributed systems just likely in operating systems what if two or more requests are initiated in a distributed system? This state is known as race condition.

Note: There exists no such of race condition because there is no parallelism where race condition bring into designing systems when there is work with some level of parallelism.  

How to handle Race Conditions in Distributed Systems?

1. Simple solution: Combine the check for whether a change is allowed with the request to make the change. 
2. Tricky Solution: Refactor the validation logic into customer validation service. As most countries have rating sorts of services, companies have internal blacklists and customer information held internally. Here we can determine whether we should do business with specific customers or not.

Above are the two ways in which the second way is used as systems are distributed worldwide but it does not rule out other solutions as the above-listed solution is used when systems are monolithic or just scaling up to distributed systems.