Monolithic and Distributed Architecture

Hey everyone!

In this blog, we’ll explore monolithic and distributed architectures in system design. This post is part of the System Design for Beginners Series.

If you’re completely new to this, my suggestion is not to overwhelm yourself with too much information. Understand what you can and move ahead ( let the future you suffer 😉 )

Monolithic Architecture

In Monolithic architecture, all the components and functionalities of a project are in a single codebase.

So college students like me usually create the frontend and backend in a single folder and then push the code to GitHub. (This is the most relatable example I can think of 🙄)

All of your frontend, logic, and database are in a single folder.

1. Latency : Latency is low ( 👍). As all the components are together on the same computer, communication within is fast.
2. Throughput : The potential for increasing throughput is low (👎) . To increase throughput, we will have to upgrade hardware.
3. Availability : Availability is low (👎). There is a single point of failure. If any bug occurs, the whole system will be unavailable.
4. Consistency : Consistency is high (👍). The server can directly communicate with the database. Hence, consistency can be managed easily.

Pros

• Less Complex
• All Modules are in a single system, so there are fewer network calls
• Integration is easy

Cons

• If there is bug in one module, it will affect the whole system
• If we want to update anything, we will have to deploy everything again.

Distributed Architecture ( Microservices )

Distributed architecture is a collection of individual systems connected through a network that share resources, communicate, and coordinate.

Consider this: you are deploying your frontend and backend separately. You can further divide your backend, like a

• A server for handling authentication
• Another server for handling products, and so on.

Authentication and handling products are all services that our system is providing. Dividing each service and deploying it separately, hence called microservices. ( make sense now🙂✌️)

1. Latency : Latency is high(👎). As components are deployed individually, it will require more network calls, hence the higher latency.
2. Throughput : The potential for increasing throughput is high (👍). To increase throughput, we will add more servers and replicate the service.
3. Availability : Availability is high (👍). There is no single point of failure. If any bug occurs, only that service will be down, but other services will work.
4. Consistency: Consistency is low (👎). Multiple services can access the database at the same time.

Microservices Architecture

Pros

• Can be scaled horizontally ( more servers can be added)
• There is no single point of failure

Cons

• Security is complex, as we also need to encrypt communication between services and databases.
• Data may be lost travelling from one server to another.

That’s all for today, folks. Catch up with this series later for more updates on System Design Basics from your host and dost — Bhavesh

If you found this helpful, feel free to like it and share your thoughts in the comments! ✨

Next up, we’ll dive into CAP Theorem

CAP Theorem