Hello there, How is it going?
Welcome to 8bitmen.com

This article is a comprehensive write-up on How to pick the right architecture for your app? The article lists down different use cases which might be applicable to your requirements.

For all the articles in the pick the right tech stack series navigate here

So, without any further ado.
Let’s get started.

 

1. USE CASE

This Is the Defacto & the Most Common Underlying Architecture In Our Day to Day Apps Such As a Social Network,

An Online Grocery Booking Website, A QnA Website, A Music Streaming App Or A Web-based Online Massive Multiplayer Game etc.

The websites stated above are the most common type of apps we browse through in our everyday lives. And almost all of them have an underlying client-server architecture.

The user interface is rendered on the client, which is typically the browser, & all the information is exchanged to & fro between the client & the server dynamically complying to a request-response communication model.

The diagram below represents a client-server architecture:

8bitmen.com client server architecture

 

2. USE CASE

Do You Want to Build a Simple Web App, Intended to Handle a Limited Amount Of Traffic?

You Are Certain that the Traffic On the App Won’t Grow Exponentially Over Time.

And the App Won’t Have Several Complex Features? You Might Be In the Initial Stages Of Your Business & Plan to Scale Out At a Later Point In Time

In this case, we can pick the monolithic web app architecture. In a monolithic application, one single codebase contains the entire application code. It is a self-contained, single-tiered software application unlike the microservices architecture, where different modules are responsible for running respective tasks/features of an app.

In a monolithic web-app all the different layers of the app, UI, business, data access etc. are in the same codebase. Monolithic apps are simple to build, test & deploy in comparison to a microservices architecture.

There are times when during the initial stages of the business, teams chose to move forward with the monolithic architecture & then later intend to branch out into the distributed, microservices architecture in future.

Well, this decision has several trade-offs. And there is no standard solution to this.

In the present computing landscape, the applications are being built & deployed on the cloud. A wise decision would be to pick the loosely coupled stateless microservices architecture right from the start if you expect things to grow at quite a pace in the future. Because re-writing stuff has its costs. Stripping down things in a tightly coupled architecture & re-writing stuff demands a lot of resources & time.

On the flipside, if your requirements are simple why bother writing a microservices architecture. Running different modules in conjunction with each other isn’t a walk in the park.

The diagram below represents a monolithic architecture:

8bitmen.com Monolithic architecture

 

3. USE CASE

Does Your App Has a Lot Of Features & Would Be Pretty Large In Size? Things Are Expected to Grow At a Pace & Would Become Complex In Near Future?

If your app contains a lot of features, for instance, messaging, real-time chat, video streaming, image hosting etc. Pick the microservices architecture, right from the start.

In a microservices architecture, different features/tasks are split into separate respective modules/codebases which work in conjunction with each other forming a large service as a whole.

This particular architecture facilitates easier app maintenance, feature development, testing & deployment in comparison to a monolithic architecture. Imagine accommodating every feature in a single repository. How complex things would be? It would be a maintenance nightmare.

Also, since the project is large, it is expected to be managed by several different teams. When modules are separate, they can be assigned to respective teams with minimum fuss, smoothening the development process.

And did I bring up scalability? To scale, we need to split things up. We need to scale out when we can’t scale up further. Microservices architecture is inherently designed to scale.

The diagram below represents a microservices architecture:

8bitmen.com Microservices architecture

 

4. USE CASE

Do You Want to Get Rid Of the Backend Server Totally, Not Worry About It? And Would Just Go With the Client-Side App, Make the App Scale Inherently?

There are instances when we do not want the server instead just want to proceed with the client-side code. For instance, like P2P peer to peer web apps like YaCy, a P2P distributed search engine or LiveStation, a P2P live TV & radio service by Microsoft.

There are social networks, also called the decentralized social networks, built on the peer to peer architecture. The underlying architecture is known as the Federated peer to peer architecture. An example of this is a decentralized social network called the Diaspora.

There are reasons to not have a server. When there is no server, there is no central authority. Every user logged into the app has equal rights. There is no form of censorship.

Also, it’s hard to restrict these kinds of apps since you cannot just put down a server & shut down the app. The app is distributed with everyone hosting it in a peer to peer architecture. Even if a few nodes go down, the app as a whole is still up & would still be up even if a single system in the world hosts it.

Also, we do not have to worry about the scalability of the app since the more users login into the app, the more scalable it becomes. If you are not clear about what p2p peer to peer is? This is a good read.

The diagram below represents a Federated peer to peer architecture:

8bitmen.com peer to peer federated architecture

 

Well, Guys!! this is pretty much it. A few things…
If you liked the article, do let me know in the comments. Share it with your folks.

This doc is continually updated as the technology evolves.

For all the articles in the pick the right tech stack series navigate here

 

More On the Blog

How Hotstar scaled with 10.3 million concurrent users – An architectural insight

How to pick the right front end language for your app – explained with use cases

A thorough insight into what is a cloud architect & why should you become one

What database does Facebook use – a deep dive 

How does PayPal handle billions of messages per day with Reactive Streams?

How many developers do you need for your startup? – A deep dive

 

You can follow 8bitmen on social media, do subscribe to the browser notifications for updates on the new content on the blog.

I’ll see you in the next article
Until then…
Cheers