What is intuition? We often hear that "This is very intuitive." Intuition in simple terms is the ability to comprehend in a natural way. Intuition is also a function of one's background and experience. Intuitive for one may not be the same for others. For example, a painter knows how with a couple of strokes and adjustments of colours he or she can change the mood of the painting. But that capability has been built through years of practice. That is why I consider intuition as a relative term and not an absolute one. Intuitive for one may not be so intuitive for others. That also leads to another interesting thing that people interpret things based on their experience and background. Confirmation bias has a role to play here but it also is a function of the tendency to put lesser mental load while comprehending a thing. We are driven by our intuition and our intuition is a function of our experience and background.
It is important to be aware of this fact as this impacts the way we function on a day to day basis. We do it in a very natural way but that may not be the best thing to do. Intuitive build-up plays a strong role in how we take any decisions and it has a profound effect on system design and architectures. Though it is very valid in all situations in life, I will limit the discussion here on systems design and architecture. System designs are very important to get right because that is one big factor that drives ease of functionality building, performance, scalability etc. in the long run.
What is system design in the context of software? System design is a high-level architectural view of a system. We all fairly understand that what all it takes so I will not get into the details of defining the elements of system design. What we will delve on is how we approach system design from the perspective of our intuitive build up.
Usually in the industry, I have seen two contrasting mindsets. It is of course not black and white and lot of gray exists in the middle. The two mindsets which though surface very prominently is monolithic and distributed mindset.
Monolithic mindset tends to design everything tightly coupled so that the mental grasp is easier and there is a fine control on everything. Scalability is usually achieved by scaling up hardware or fine-tuning the algorithms to the maximum. This is also termed as vertical scaling.
Distributed mindset, on the contrary, decouples everything. Horizontal scaling is the way to achieve scalability. The design inherently allows throwing more clusters.
A very good example of monolithic vs distributed is SQL vs no SQL databases. SQL databases are designed to be vertically scalable. They offer sharding or horizontal distribution but that usually is an afterthought. No SQL databases scale horizontally. The distribution is built in the core.
However, this does not mean that one is better than the other. They both have their pros and cons. Monoliths are easy to bring up and light on resources. Most of the applications are good being monolith. They are light on resource needs also. Easy to build and maintain. Distributed architecture is hard to get right and they don't turn right it is very hard to refactor them. However, once the architecture is correctly placed scalability is very easy to achieve. Building distributed systems initially is a challenging task but longer-term it pays off if you are really in the need of a scalable application.
Coming back to our discussion on intuition, what happens is people tend to design based on their experience, and that may not be the right thing to do. It is important to step back and understand the needs of the application and design accordingly. Do watch out for your experience not kicking in at the wrong moment.
What kind of mindset you have got? Imagine building a system like Twitter, how would you do it? Do you think in a monolithic way or in a distributed way? Put your thoughts in the comment section and we can discuss.
No comments:
Post a Comment