search

learncsintamil / comments

0 stars 0 forks source link

courses/turn-your-software-ideas-to-reality/kalvify-tech-stack #5

Open utterances-bot opened 3 years ago

utterances-bot commented 3 years ago

Kalvify's Tech Stack

Screencast tutorials to help you learn Computer Science & Software Development in Tamil. Videos to help you learn HTML, CSS, Javascript, and more.

https://www.learncsintamil.com/courses/turn-your-software-ideas-to-reality/kalvify-tech-stack

karthik19894 commented 3 years ago

Great explanation on the tech stack Tamizh, I would be glad to know your thoughts on design for scale from the start, do you already have a plan in mind when your application is going to be used by large number of audiences? It would be great if you could also explain your thought process in deciding between Micro-services and Monolithic architecture.

tamizhvendan commented 3 years ago

Good question, @karthik19894.

The word "Scale" is often misused/misinterpreted in software development. For a typical business line of application, any standard tech stack of any high-level language will work and scale right out of the box if we build it right by following the two principles, Loose Coupling & High Cohesion.

Other than these two, I won't do much about scaling when I am starting a project/product. However, if the problem statement demands it, I will bring it to the equation.

For example, "Kalvify" is going to be a write-Less (course creation/update), Read Heavy (with more audiences). There are multiple ways to scale the read operations. Denormalizing the data, caching, pre-generating/pre-computing the pages are few ways. So, for Kalvify, I will play the "wait and watch" game and act on it when it really demands.

On the other hand, If I am building a product that demands scale or fault tolerance right from the start, like Road Traffic System or Web Analytics (Google Analytics Clone), I tend to choose the appropriate language, ecosystem, and architecture.

Talking about Microservices vs. Monolithic, it requires a course on its own. The challenge with microservices is the word "Micro." We don't know the exact size of the "Micro" at the beginning. The examples/talks that we see in the wild would sound good on paper, but the reality is hard because distributed systems are hard.

So, I tend not to choose "Microservices" architecture right from the beginning. Instead, I focus on building a modular monolith with a cleaner separation of concerns. As it is following the loose coupling, it is microservice ready at any point in time. When it really matters, I will pull it out, but till then, I will be happily building majestic monoliths