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
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!