Node.js Backends and APIs Built to Survive Growth

For I/O-bound work — database queries, API calls, file handling — yes, and that's most backends. Node struggles with sustained CPU work like heavy image or video processing, because that blocks the event loop. The answer there isn't abandoning Node; it's moving that work to a queue or a service better suited to it.

REST unless you have a specific reason. GraphQL genuinely helps when many different clients need different shapes of the same data, and it brings real costs: caching is harder, and you have to guard against expensive nested queries. Choosing it by default is a common source of avoidable complexity.

PostgreSQL for most products. Relational data with real constraints is the common case, and Postgres handles JSON well when you need flexibility. MongoDB suits genuinely document-shaped data with varying structure. Picking Mongo to avoid writing a schema usually means writing it later in application code, less reliably.

In our experience, usually one of three: a missing database index, an N+1 query pattern that was invisible at small data volumes, or CPU work on the request path blocking the event loop. All three are diagnosable with tracing, which is why we'd measure before proposing changes.

Yes. We read it, check dependency and security posture, and report what we find before proposing work. Most backends need targeted fixes rather than the rewrite people assume.