DEV Community: Muhammad Usman

System Architecture Design Methodologies Part 3

Muhammad Usman — Fri, 26 Jul 2024 22:00:19 +0000

This is the last part of our system architecture design methodologies series. Don’t forget to checkout Part 1 & Part 2 as well.

Layered (n-tier) Architecture

In simple words, this architecture divides a software system into layers. These layers are also called tiers. These layers help with managing, developing, and deploying the components. This architecture is mainly for large-scale applications where scaling is crucial, and managing the code is complex. The most common layers are

User Interface/Presentation Layer

Business Logic/Application Layer

Data Access Layer (ADL)

Pros:

Each layer has a specific role. This makes the code cleaner, independent, and easy to understand.

Usability of the components and functionality increases because of the isolation.

Maintainability and debugging become easier.

Cons:

Adding layers increases latency. This may hurt performance.

Be mindful of using this architecture. You may overengineer if your application is small.

If not careful, layers may become tightly coupled. This makes it difficult to modify and scale the system.

CQRS (Command Query Responsibility Segregation)

It separates reading from writing. Reading side handles queries (SELECT) whereas the writing side handles commands (create, update, and delete) CQRS is well-suited for e-commerce, finance, and real-time analytics systems.

Pros:
By separating the reading and writing on each side, it becomes independent and easy to scale.

Separating concerns reduces complexity, making modifications straightforward.

Testing and debugging becomes easier.

Cons:
Data may not be consistent across all the nodes. This is especially true if there are multiple writers.

This architecture relies on eventual consistency. The data may be stale, which might cause issues.

It has a steep learning curve.

Peer-to-Peer Architecture (P2P)

P2P is a decentralized network of interconnected components. In P2P, each node can function as both a client and a server simultaneously. In a P2P world, there is no central server or authority that can control or manage the flow of information. Instead, each node is responsible for its own data and communication. Bitcoin is a prime example of P2P architecture.

Pros:
Because of its decentralized nature, there is no single point of failure.

Scaling P2P is easy. You can add new nodes to the network without harming performance.

P2P can reduce the need for large, costly infrastructure, which makes it cost-effective.

Cons:

P2P networks can be vulnerable to security risks because of its decentralized nature.

P2P networks can raise legal issues. These include copyright infringement and data privacy problems.

The quality of service can vary depending on the performance of the node.

System Architecture Design Methodologies Part 2

Muhammad Usman — Thu, 18 Jul 2024 12:12:45 +0000

This is part II of my previous post on System Design methodologies. In the previous post we discussed Monolithic, Microservice and Service Oriented architectures. Today we will learn about Domain Driven Design(DDD), Event-Driven Architecture (EDA) and Serverless architectures.

Domain-Driven Design (DDD): Domain-Driven Design (DDD) creates software that mirrors business requirements precisely. It's like creating a map of the business world, and then using that map to build the software.

DDD helps make sure that everyone is involved in building the software. The developers, stakeholders, and field experts all know what the software needs to do. This way, the software can be built to meet the real needs of the business, and not just what someone thinks it should do.

Pros:

DDD emphasizes on understanding the business domain.

It promotes creating modular software. The software is easy to maintain and adapt to business changes.

It also encourages using aggregates to boost scalability and performance. They do so by cutting database queries and improving data consistency.

Cons:

DDD has a steep learning curve for developers. It takes a lot of time and effort to learn and use its principles.

It can lead to a complex software system, particularly if not implemented correctly

Implementing DDD can be expensive at first. It includes training, consulting, and development time. This may not be possible for all organizations.

Event-Driven Architecture (EDA): EDA is a framework that processes events and reacts to changes in a system. It does it asynchronously. In EDA, an event occurs when something happens or is about to happen. The event triggers a reaction in the system. Follow these steps to implement EDA.

Identify the events that will trigger reactions in your system.

Design the event handlers that will react to the identified events.

Create an event bus that enables publishing and subscribing to events.

Implement an event store that stores all the events that have occurred in the system.

Test and debug your EDA system to ensure it works as expected.

Pros:

EDA enables real time processing of events which helps in immediate processing

It is easy to scale horizontally, more event handlers can be added into the system easily

EDA is loosely coiled which makes it easy to modify and scale.

Cons:

EDA can introduce complexity particularly when there are multiple event producers.

Debugging and testing are hard because the architecture is asynchronous.

EDA systems can have issues with event versioning. Changes to event structure can break compatibility with existing handlers.

Serverless Architecture: Serverless architecture is a cloud computing model. In it, the cloud provider manages the infrastructure. The developer only writes and runs code. The term "serverless" doesn't mean no servers exist. Instead, it means the developer doesn't need to provision or manage servers.

In serverless architecture, the application is broken into small, separate functions. They can be run on demand. Programmers usually write these functions in a language like Node.js, Python, or Go. They deploy them to a cloud platform such as AWS Lambda, Google Cloud Functions, or Azure Functions.

When a user makes a request, the cloud platform automatically provisions the resources. These resources include servers to run the function. The function is executed, and the result is returned to the user. Once the function has finished, it releases the resources. The developer only pays for the time and resources used while the function ran.

Pros:

Pay only for the time and resources used during the execution of the function. It become a cost-effective option.

Serverless architectures can scale automatically to handle changes in traffic.

Serverless architectures can be highly available. The cloud provider manages the infrastructure and ensures the application is always available.

Cons:

The first time a function is executed, it may take longer to start up, which can lead to slower response times.

You may become locked into a specific cloud provider's ecosystem. It makes it difficult to move to another provider.

Debugging and testing serverless applications can be challenging. Because the developer doesn't have direct access to the underlying infrastructure.

System Architecture Design Methodologies Part1

Muhammad Usman — Tue, 16 Jul 2024 21:16:34 +0000

System Architecture Design Methodologies are like recipes for building complex systems. These methods provide a framework for architects to follow. They design the system for flexibility, simplicity, and consistent performance. Here are some common System Architecture Design Methodologies:

Monolithic Architecture: This approach builds the entire system as a single, self-contained unit. It is often used for smaller applications or proof-of-concepts.

Pros:

Since there is a single codebase, it makes it easier to develop, test, and debug.
Deployment is often faster and more straightforward.
It is relatively easier to optimize performance because all components are co-located.

Cons:

A single codebase simplifies deployment, but hinders scaling. As the application grows, adding resources forces you to scale the entire application.
Components are tightly coupled. This makes it hard to change them without affecting the whole system.
It has a single point of failure.

Microservice Architecture: In this approach, a single application consists of many small services. They are independent and loosely coupled. Each service is designed to perform a specific task.

Pros:

You can easily scale up or down each microservice. You do this depending on if demand increases or decreases.
If a particular microservice is down, the rest of the system will not be affected.
Maintaining a smaller, independent component is easy. It is easier than making changes in a monolith repository.

Cons:

Managing multiple services can be more complex than deploying a single application.
Tracing problems gets harder. You might need to search through many services to find the problem.
Services communicating over a network can increase latency. But, this may not be true in a monolith architecture.

Service-Oriented Architecture (SOA): SOA is a middle state. It is between monolith and microservices architectures. SOA takes a hybrid approach. It keeps some coupling between systems, but not as much as in a monolith. SOA typically involves large, complex services. They have a lot of business logic. Microservices are smaller and focused. They perform a specific task or function.
Pros:

Easier to implement than a microservice, as it requires less complex infrastructure.
SOA is well-suited for small-scale applications that don't require much scalability.
SOA has a centralized management approach, which makes governance easier.

Cons:

SOA services are often scaled vertically. This makes it hard to scale them horizontally.
SOA services are tightly coupled, making it harder to make changes.
The maintenance cost for SOA services could be higher if not set up properly.