> For the complete documentation index, see [llms.txt](https://shimozurdo.gitbook.io/frontend/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shimozurdo.gitbook.io/frontend/node/clusters-vs-child-process.md).

# Clusters vs child process

En Node.js, **clusters** y **child processes** son dos mecanismos distintos para aprovechar el poder de múltiples núcleos de CPU, pero tienen diferentes propósitos y formas de funcionamiento.

#### Diferencias Principales entre Clusters y Child Processes

1. **Propósito y Estructura:**
   * **Clusters**: Están diseñados específicamente para manejar múltiples solicitudes HTTP en paralelo mediante la creación de múltiples instancias de un servidor de Node.js. Cada instancia (o *worker*) es un proceso hijo que comparte el mismo puerto y permite que múltiples usuarios interactúen con el servidor sin sobrecargar un único proceso.
   * **Child Processes**: Son procesos secundarios generales que permiten ejecutar comandos del sistema o scripts independientes desde una aplicación Node.js. Los child processes son útiles para tareas intensivas en CPU o para ejecutar scripts externos, no necesariamente vinculados a servidores HTTP.
2. **Implementación:**
   * **Clusters**: Utilizan el módulo `cluster`, el cual configura automáticamente un proceso maestro que crea y gestiona procesos *worker* que manejan solicitudes en paralelo.
   * **Child Processes**: Utilizan el módulo `child_process`, que ofrece varias formas (`spawn`, `exec`, `execFile`, `fork`) para crear procesos secundarios que pueden ejecutar cualquier comando o script. Los child processes no tienen relación directa con la creación de servidores o el manejo de conexiones HTTP.
3. **Comunicación entre Procesos:**
   * **Clusters**: Los *workers* en un clúster comparten el puerto del servidor y pueden comunicarse con el proceso principal mediante un canal de intercomunicación (IPC), que viene configurado por defecto con el módulo `cluster`.
   * **Child Processes**: La comunicación entre el proceso padre y el proceso hijo puede hacerse a través de mensajes utilizando el canal IPC, pero debe configurarse de forma explícita y depende de los métodos (`spawn`, `exec`, etc.) usados para crear el proceso.
4. **Uso de Memoria:**
   * **Clusters**: Dado que cada *worker* en un clúster es un proceso independiente, cada uno tiene su propio espacio de memoria, por lo que usar clusters en sistemas con recursos limitados puede consumir más memoria.
   * **Child Processes**: También consumen memoria por ser procesos independientes, pero su uso es más flexible en cuanto al número de procesos necesarios, ya que no están limitados a un servidor HTTP.
5. **Manejo de Errores y Tolerancia a Fallos:**
   * **Clusters**: Cuando un *worker* falla, el proceso maestro puede detectar el error y crear automáticamente un nuevo *worker* para mantener la disponibilidad del servicio.
   * **Child Processes**: Los child processes no tienen un proceso supervisor como el clúster, por lo que cualquier manejo de fallos debe implementarse explícitamente.

#### ¿Cuándo Usar Clusters vs. Child Processes?

* **Clusters**: Útiles para aplicaciones que manejan múltiples solicitudes en un servidor HTTP y necesitan aprovechar varios núcleos de CPU. Es común en servidores web que requieren alta concurrencia y disponibilidad, como aplicaciones de APIs REST.
* **Child Processes**: Son más flexibles y se usan para tareas específicas, como el procesamiento intensivo de datos, la ejecución de scripts externos o el manejo de procesos en paralelo que no necesariamente están relacionados con el servidor HTTP.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://shimozurdo.gitbook.io/frontend/node/clusters-vs-child-process.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.