How do you decide when a Node.js service should be split apart, or when separate services should be merged?

Answer with criteria rather than a preference for microservices or monoliths — strong candidates are known for resisting both dogmas.

Reasons to split:

• Different scaling profiles. A video transcoder and a login endpoint do not want the same instance count or the same machine.
• Different failure requirements. If the reporting dashboard falling over must never take payments down, that boundary is real.
• Different teams and release cadences. If two teams block each other on every deploy, the seam is organisational as much as technical.

Reasons to merge, or to never split:

• The two services always change together, so every feature becomes a two-repository, two-deploy exercise.
• They share a database, in which case they are one service wearing two hats.
• You cannot afford the operational cost — tracing, deploy pipelines, and on-call all multiply.

Note: Saying you would start with a well-structured single service and split when a specific pain appears is a defensible and increasingly common position.