System Architecture Design Methodologies Part 3

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.

**