It is doable in Go and it is doable in Node. It is doable in other languages like Erlang or Python as well. But since you're asking about Node then this is what I'll answer about.
The most important thing for high concurrency in Node is to never block the event loop or do any blocking operation ever (unless it's the first tick of the event loop). This is the number one thing that people do and ruin the concurrency - like putting a little innocent-looking fs.statSync() now and then (see this answer for examples of such mistakes right in the answers on Stack Overflow). Using any blocking operation (including long running for or while loop) after the first tick is always a mistake and in fact I think it should throw exceptions.
Another thing that while not being an outright mistake in all situations may still harm the scalability is storing any state in your application. If you need to have any persistent state (and try to minimize that need at all cost) then you should use a database for that. For data that needs to be shared between requests quickly like session data you should use a fast database like Redis, but only if you cannot achieve the same with things like JWT etc.
Prefer horizontal instead of vertical scalability, because at some point there will be no bigger server, but there will always be more servers.
To sum it up:
- Never block the event loop
- Do all CPU-heavy computations in external processes
- Never block the event loop
- Use Redis or Memcached for shared state
- Never block the event loop
- Use clustering for horizontal scalability
- Never block the event loop
Did I mention never blocking the event loop?
