Node.js is a good way to go and has served me really well on a number of projects/fronts. However, Python is totally viable as well. Where node.js will not serve you well is if your api is blocking in nature. For those cases when we have a blocking call, we will send that call off to a queue and let a worker node pick it up and deal with it, saving our API from having anything blocking.
As for scalability/availability, Python can be just as scalable and available as node.js in my opinion, but you have to take some different routes to get there. The best recommendation I have is keep it simple and clean with each endpoint doing only one thing.
I am anal about making sure any API endpoint I develop is very short and to the point, and does only 1 thing. For example, I don't like having a POST endpoint that saves three different records to a database, that should be three separate calls or a queued message to be processed by worker processes. This type of design makes your api far easier to maintain. The drawback of course is multiple calls and potentially more endpoints. But another benefit of designing it this way is that I can scale certain API endpoints individually and only add the complexity of scale where needed. In some cases too you can have an endpoint that implements some chain of responsibility to handle multiple calls and may be blocking, but this would be layered on your individual endpoints.
It takes a RAML file and spits out a production-ready API. It supports Postgres, Mongo and Elasticsearch our-of-the-box.
AMA, I'm a core dev, and happy to help.