 |
VOOZH | about |
|
VOOZH | about |
System Analysis and Design is the process of understanding business requirements and creating a structured solution to meet those needs. System analysis focuses on identifying problems and gathering requirements, while system design focuses on building the architecture and components of the system.
Now that we understand system analysis and how it differs from system design, it is important to explore the major types of systems used in system design. These systems define how applications are structured and deployed in real-world scenarios.
Generally, systems can be categorized into two main types:
A monolithic application is a software system where all functionalities exist within a single codebase. It is built as one large, unified block, with tightly integrated components that are developed and deployed together.
The Monolithic system architecture can be visualized by considering three sections or three layers:
Monolithic architecture is simple to build and manage, making it suitable for small to medium-sized applications.
Tip: Monolithic architecture is commonly used by organizations in the early stages because it has fewer cross-cutting concerns such as caching, logging, and handling. Since everything is managed in a single system, it becomes easier to develop, debug, and maintain initially.
Monolithic architecture can become difficult to manage and scale as the application grows in size and complexity.
Microservices is an architectural style in which an application is built as a collection of small, independent services. Each service handles a specific functionality and communicates with other services using lightweight protocols such as HTTP.
The Microservice architecture has a significant impact on the relationship between the application and the database.
Microservices architecture improves scalability, flexibility, and system resilience by dividing the application into independent services.
Despite its benefits, microservices architecture introduces complexity and operational challenges.
This comparison highlights the key differences between monolithic and microservices architectures in terms of structure, scalability, deployment, and maintainability.
| Monolithic Architecture | Microservice Architecture |
|---|---|
| Single-tier architecture | Multi-tier architecture |
| Built as one large application with tightly coupled components | Composed of small, loosely coupled services components |
| Deployed as a single unit | Individual services can be deployed independently |
| Horizontal scaling can be challenging | Easier to scale horizontally |
| Development is simpler initially | Development is more complex due to multiple services |
| Technology stack choices are usually limited | Freedom to choose the best technology for each service |
| Entire application may fail if a part fails | Individual services can fail without affecting others |
| Easier to maintain due to its simplicity | Requires more effort to manage multiple services |
| Less flexible as all components are tightly coupled | More flexible as components can be developed, deployed, and scaled independently |
| Communication between components is faster | Communication may be slower due to network calls |
When adopting a Microservices architecture or migrating from a Monolithic architecture, it’s not feasible to handle all components on a single system—doing so would contradict the modular nature of Microservices. This is precisely where Distributed Systems come into play.
Distributed Systems not only bring modularity to your architecture but also provide a foundation that makes implementing Microservices more efficient and effective. They enable seamless scaling, independent service deployment, and better resource utilization, allowing you to fully leverage the benefits of a Microservices approach.
A Distributed System is a collection of independent computers connected through a network that work together by sharing resources to achieve a common goal. These systems communicate and coordinate with each other to perform tasks efficiently and reliably.
In a distributed system, data is replicated across multiple geographically distributed servers. If one node fails due to issues like power failure, the replicated data on other servers remains available, ensuring reliability and fault tolerance.
Example: Telecommunication Networks
Distributed systems provide high scalability, reliability, and improved performance by using multiple interconnected machines.
Despite their benefits, distributed systems introduce complexity in management, communication, and data consistency.
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.
A race condition occurs when multiple processes or services execute concurrently and the final outcome depends on the timing or order of execution. It typically arises in systems with parallelism where shared resources are accessed without proper synchronization.
Race conditions are commonly seen in operating systems and also occur in scalable systems where multiple requests are processed at the same time, leading to conflicts or inconsistent results.
Example: Consider a banking system where multiple microservices handle operations like credit card approval. Suppose a service checks a user’s CIBIL score before approving a credit card.
Now, if multiple requests for the same user are processed simultaneously, two services might read outdated data and both approve or reject incorrectly. This overlapping of operations leads to a race condition.
Note: Race conditions are very common in distributed systems because multiple services and nodes process requests concurrently. Due to this parallelism, operations may interleave in unpredictable ways, leading to inconsistent or incorrect results if not handled properly.
Proper handling of race conditions is essential to ensure data consistency and system correctness.
