As @copleykj and @martineboh said Meteor is Node.js, and ultimately you decide what parts of it you want to use. Meteor comes with tons of useful stuff, therefore moving away from it doesn’t seem like a good idea – at least not for the reasons you mentioned.
If your app is arriving at hundreds of millions of transactions per month, then you will have to consider very carefully whether you can still leverage Meteor’s reactivity, and to what degree and how exactly. If you decide that you do need reactivity, your best bet is still Meteor, because realistically there is no way that a small team could magically come up with a purely Node.js-based pub/sub reactivity solution that outperforms what was developed into Meteor in several years of work by dozens of experts.
Plus, if you’re expecting hundreds of millions of transactions per month, then it means that your business is skyrocketing, so you should be prepared to see that volume on a per day basis quite soon. Meaning: your architecture needs to be a) zero downtime and b) infinitely scalable.
Meteor is a client-server framework to build modern webapps. It’s not necessarily true that all of your transactions will have to be routed through your very webapp. If I were you I would consider to introduce at least one auxiliary system that takes to heat, so that all the heavy load is diverted away from your Meteor app.
Realistically your clients will not want to constantly drill down into the data of the hundreds of millions of transactions: they will want to see aggregated data most of the time. So you will have to cope with the challenge of the large amount of transactions when they occur and provide a view to the aggregated data (per customer) in a reactive way: those are two different stories.
I was involved in the development of a digital advertising solution, an SSP (Supply Side Platform) for RTB (Real Time Bidding) in the capacity as Head of Development and Lead Architect. We’ve had 4 billion (! not million) incoming requests per day (! not per month) and one hundred billion (! not million) outgoing requests per day, and with the proper architecture and stack this was perfectly doable, 24/7, zero downtime, infinitely scalable. Of course it wasn’t Meteor / Node.js stack, but the principles are the same.
Re: Galaxy – I don’t think you can (or should) do all of it via Galaxy. As they say, if all you have is a hammer, everything looks like a nail, and you should avoid that fallacy. For the volume you anticipate you will need an architecture far beyond a single Meteor app. I think you do need a Meteor app, that’s quite good, but you will probably need more items in your puzzle.