First off. As someone else pointed out it depends on the application. Heavily data dependent / ETL applications have different requirements than CRUD applicati

First off. As someone else pointed out it depends on the application. Heavily data dependent / ETL applications have different requirements than CRUD applications. There is not a one size fits all stack, you need to consider the user cases. For example: - We use DynamoDb and ElasticSearch on the back-end because our case is very key-value oriented but also needs faceted search in some use cases. - We use Node.js for our user-facing REST API because it was fast to develop and quick to iterate on but we use GoLang for our internal gRPC APIs and front-end because in our case those are the hot paths and where the performance differences between node and Go make a difference. For an activity feed API (hundreds of thousands of activities a day) I've used Redis with huge success. The point being is if your app is truly enterprise you'll probably have more than one microservice, and you should pick the right stack for each microservice. In absence of a hard business requirement that is significantly different between languages choose the framework your team can develop the fastest in and get to market fastest (like our hot path example). My personal go to is... Backend: Postgres, Redis, Elasticsearch, DynamoDb Front-end server and APIs: Node.js with express (no framework), focusing on as few lines of code per microservice as possible OS: Definitely Linux Cloud Provider: AWS Cache: Cache close to the app when possible, if you don't need cache to be synchronized across machines there is no need for a central cache. With that said, I personally love Redis On the cloud platform note, I'm an AWS guy but they all have their benefits. I try to use as many AWS services as possible to decrease dev time / costs but write the code in such a way where it is abstracted so getting away from vendor lock-in would be possible (painful but at least possible). All the cloud providers have a service catalog that can shorten your development time if you take the time to learn them use them right. I happen to like AWS value added services best. With all that said: - The most important things you should worry about is getting to market and solving the customer's use case. The stack is not important in 90%+ of cases. If you structure as microservices you can always replace individual services cheaply on a case by case basis once you have customers. - Second, "When I ask tech stack I'm talking the whole dam thing" is very unprofessional and I almost didn't answer because of that. I suggest perhaps an attitude adjustment when asking the community for free consulting advice.