Designing Architecture that Scales with your Product

Designing server architecture to support multiple applications can be a very tricky and intimidating task to take on.  So many different things need to be considered when designing your first initial implementation that often times engineers will find themselves over engineering an achitecture all at once instead of building for their immediate needs and planning to scale over a period of time.  For example, when considering a server architecture for any kind of product most engineers know that they will need to support mobile applications, web applications, multiple forms of authentication, variable traffic loads, caching, file syncing, database replication, and staging environments at some point.  However, are all these features are not required as your product initially gets off the ground?  Probably not.  Probably only a select few are needed.  I have seen many cases where system engineers overload their initial infrastructure build with too many pieces all at once and bog down the ability to scale a product as rapid growth starts to occur.  In the following two paragraphs I will provide two essential techniques that I have always used to grow a product and keep it scalable over the long term.

1) Consolidate as Much as Possible

The first bit of advice is very literal and means exactly what it says; off the bat, keep your languages and servers as consolidated as possible.  Often, when thinking about the entire product and all of the components involved there is a tendency to over engineer things and engineers get caught in the trap of using the newest languages and the newest technical trends without really realizing the long term impact.  This can lead to pitfalls though as you want to scale your product and scale your code.  As your product becomes larger and more engineers are needed to scale your product it will take more and more ramp-up time on a per-engineer basis if there is multiple languages at play across multiple server environments then if your languages and environments were more consolidated from the start. 

In the long term there may be a need to rebuild some of your infrastructure, however, that is OK, and totally appropriate if you have the data to back up a good use-case in why the rebuild might be appropriate.  Many of the most successful companies have rebuilt their infrastructure five or ten years down the road in production, but the benefit in getting to that point with a consolidated code base is that you did not have to spend three times your engineering budget each year to get there.

2) Avoid Decoupling, it will Cost Time and Money

I am as guilty as the next engineer in getting lost in the decoupling craze.  I wanted to build a sub-system, a microservice, and a front-end client for everything when this craze first hit the tech world a couple years back.  Having said that, and built many clients and microservices over the years, very rarely is there a good use case for these items and the majority of the time it just ends up costing the company too much maintenance and engineering overhead.  It divides your team's efforts instead of consolidating them and focusing them on a few specific code bases that really matter to your core product.  Now, I can imagine that many JavaScript engineers and backend microservice engineers are reading this right now and thinking that I have lost my mind, but really ask yourself, if your product gets enough traffic to legitimize spreading out and decoupling your product?  I would bet that for every ten client-API architectures out there, only one or two of them have legitimate data to verify that spreading out development efforts realizes a large gain in load time.

In conclusion, start off small and start off consolidated, it will save you server and engineering money very quickly when and if your product grows.  Starting off small and consolidated means you will have the resources to scale with your product.  Do not engineer yourself into a corner up front, and remember, there is no shame in rebuilding five or ten years down the road when you have the time, resources, and data to back up the legitimacy of having a very large distributed system with many languages and environments in play.  Thanks for reading and I would love to hear your thoughts and comments!