I've got a question: Is horizontal duplication the same as horizontal scaling? If not, why have you mentioned vertical scaling but not horizontal scaling?
When I talk about horizontal duplication, I'm referring to a specific technique where you run multiple copies of your application on separate servers. It's a straightforward way to increase capacity and improve reliability by ensuring that if one server goes down, others can still handle the load.
Horizontal scaling, on the other hand, is a broader concept that includes not just duplicating entire systems but also other methods like data sharding or workload distribution across multiple nodes.
So, while horizontal duplication is a form of horizontal scaling, not all horizontal scaling involves duplication.
But it is a good clarification. Thanks for the great question, Inayatullah.
Most of the major companies started as monoliths and over time, they scaled their architecture to meet demand. Turns out that even a simple monolith can take you quite far if done properly. Each scaling strategy also adds some complexity of its own.
First option : Focus on scalability with the hardware spec without touching the application.
Second option : Focus on Duplicating the application for processing inflow requests, which has challenges w.r.t scheduling and caching.
Third option : Discussed about DB scaling and not deals with application scalability. Partitioning will help grow Db to scale.
Forth option : Scaling on the application with micro services will be a good way, and we should have each services to openup the apis for the cross services to communicate.
Would like to understand, when we say micro services, each has to run with their own database, and will it scale for onprem as well as cloud service ?
Having separate databases per service is ideal for autonomy but not always required for microservices. Although I prefer the separation, I have seen specialized microservices sharing without issue. Some teams use a shared DB with logical separation when full isolation isn’t practical.
As for on-prem vs. cloud, microservices can work in both, but cloud-native services (like managed databases, auto-scaling, and serverless options) make scaling much smoother. On-prem often requires more effort in orchestration and resource management.
Are you currently working on scaling a system on-prem, cloud, or hybrid?
Yes, when it comes to on-prem requires more effort on scaling up. Generally it can be managed by combining on scaling towards database, and also on the application side.
Exactly! Going horizontal first is a smart move; it is easy to manage, keep things simple, and, most times, it's enough to handle growth until you're ready for something bigger.
It's always a trade-off between what we can sacrifice and what we can't. In the real world, usually, we can't build the perfect solution.
The only thing that matters is the level of agility and flexibility of the solutions we create.
My go-to approach is to start as simply as possible without sacrificing the flexibility of the architecture to evolve.
Great article, Raul!
Absolutely! There’s no such thing as perfect architecture; only the best one for the current stage of growth.
Thanks, Petar.
Very Good Article!
I've got a question: Is horizontal duplication the same as horizontal scaling? If not, why have you mentioned vertical scaling but not horizontal scaling?
That's an interesting question.
When I talk about horizontal duplication, I'm referring to a specific technique where you run multiple copies of your application on separate servers. It's a straightforward way to increase capacity and improve reliability by ensuring that if one server goes down, others can still handle the load.
Horizontal scaling, on the other hand, is a broader concept that includes not just duplicating entire systems but also other methods like data sharding or workload distribution across multiple nodes.
So, while horizontal duplication is a form of horizontal scaling, not all horizontal scaling involves duplication.
But it is a good clarification. Thanks for the great question, Inayatullah.
Great article Raul.
Most of the major companies started as monoliths and over time, they scaled their architecture to meet demand. Turns out that even a simple monolith can take you quite far if done properly. Each scaling strategy also adds some complexity of its own.
Also, thanks for the mention!
Exactly!
Scaling isn’t just about breaking things apart—it’s about knowing when to do it.
Every scaling strategy has trade-offs; jumping in too early can add unnecessary complexity.
Thanks, Saurabh!
Very good article.
First option : Focus on scalability with the hardware spec without touching the application.
Second option : Focus on Duplicating the application for processing inflow requests, which has challenges w.r.t scheduling and caching.
Third option : Discussed about DB scaling and not deals with application scalability. Partitioning will help grow Db to scale.
Forth option : Scaling on the application with micro services will be a good way, and we should have each services to openup the apis for the cross services to communicate.
Would like to understand, when we say micro services, each has to run with their own database, and will it scale for onprem as well as cloud service ?
Good question, Sri.
Having separate databases per service is ideal for autonomy but not always required for microservices. Although I prefer the separation, I have seen specialized microservices sharing without issue. Some teams use a shared DB with logical separation when full isolation isn’t practical.
As for on-prem vs. cloud, microservices can work in both, but cloud-native services (like managed databases, auto-scaling, and serverless options) make scaling much smoother. On-prem often requires more effort in orchestration and resource management.
Are you currently working on scaling a system on-prem, cloud, or hybrid?
Yes, when it comes to on-prem requires more effort on scaling up. Generally it can be managed by combining on scaling towards database, and also on the application side.
I like vertical scaling the most because the operational complexity doesn't change much.
Nice article!
And it should always be the first step!
Thanks, Neo.
Solid write up my friend. Nowadays we usually go for horizontal scaling, can be nicely handled with most cloud native platforms.
Exactly! Going horizontal first is a smart move; it is easy to manage, keep things simple, and, most times, it's enough to handle growth until you're ready for something bigger.
Thanks!