Cierras el módulo con el código que se ejecuta sin que nadie lo pida: tareas programadas, sincronizaciones, generación de informes, limpiezas. Como no hay un usuario esperando, es fácil que nadie revise si ese trabajo hace falta, cuánto cuesta o cuándo se ejecuta. Y precisamente por eso, suele ser uno de los sitios con más margen de ahorro.
1 // El trabajo que nadie mira
Casi todas las aplicaciones tienen trabajo en segundo plano:
- Tareas programadas (cron jobs): «cada noche a las 3:00, genera el informe de ventas».
- Colas de trabajo: el usuario sube un vídeo y un proceso lo convierte a varios formatos cuando puede.
- Sincronizaciones: «cada 5 minutos, trae los pedidos nuevos del proveedor».
- Mantenimiento: copias de seguridad, limpieza de registros, regeneración de índices.
Recuerda el cálculo del módulo 2: una tarea que se ejecuta cada minuto son 525.600 ejecuciones al año. Si cada una tarda un par de segundos de CPU, suman casi 300 horas de procesador. Y a diferencia del código de una petición, nadie nota si esa tarea es lenta o si ya no sirve para nada.
2 // Sondeo frente a eventos
La forma más sencilla de enterarse de un cambio es preguntar periódicamente (polling, sondeo): «¿hay pedidos nuevos?», «¿ha terminado el pago?». Es fácil de programar, pero tiene un problema de fondo: trabaja aunque no pase nada.
La alternativa es la arquitectura basada en eventos: en lugar de preguntar, te avisan cuando algo ocurre.
| Técnica | Cómo funciona | Uso típico |
|---|---|---|
| Webhooks | El otro servicio llama a una URL tuya cuando hay novedades | Pagos, repositorios de código, proveedores externos |
| Colas de mensajes | Un servicio publica un mensaje y otro lo consume cuando llega (RabbitMQ, Kafka, colas de la nube) | Comunicación entre microservicios |
| WebSockets y SSE | El servidor empuja datos al navegador por una conexión abierta | Notificaciones, chats, paneles en tiempo real |
| Disparadores | La base de datos o el almacenamiento lanza una acción al cambiar algo | Procesar un fichero al subirlo |
Una aplicación de reparto tiene 5.000 clientes con la app abierta, y cada una pregunta al servidor cada 10 segundos si su pedido ha cambiado de estado. De media, cada pedido cambia de estado 4 veces en la hora que dura.
- Peticiones de sondeo por hora: 5.000 clientes × 360 consultas = 1.800.000 peticiones.
- Peticiones con novedades: 5.000 × 4 = 20.000, apenas un 1,1 %.
- Con eventos (por ejemplo, SSE): el servidor envía sólo esos 20.000 mensajes, y el cliente se entera en el momento, no hasta 10 segundos después.
El sondeo no es siempre un error. Si el otro sistema no ofrece eventos, o los cambios son muy frecuentes, preguntar puede ser razonable. En ese caso, ajusta el intervalo a la necesidad real (¿de verdad necesitas saberlo cada 10 segundos?) y usa respuestas baratas, como un 304 cuando no hay cambios.
3 // Lotes y trabajo incremental
Cuando la tarea sí tiene que procesar datos, dos técnicas reducen mucho su coste:
Procesar por lotes. Enviar 1.000 correos con 1.000 conexiones, o insertar 10.000 filas con 10.000 sentencias, multiplica el trabajo fijo de cada operación. Agruparlas en lotes (una conexión, un INSERT con muchas filas, una llamada a la API con varios elementos) reparte ese coste fijo.
Procesar sólo lo que ha cambiado. Muchas tareas nocturnas recalculan todo cada vez: todas las estadísticas, todos los productos, todas las miniaturas. Si cada día cambia el 1 % de los datos, el 99 % del trabajo repite resultados que ya existían. El procesamiento incremental guarda una marca (la fecha de la última ejecución, un campo updated_at, un registro de cambios) y trabaja sólo sobre lo nuevo.
Y una tercera, más de sentido común: revisar si la tarea sigue haciendo falta. Informes que nadie abre, sincronizaciones con sistemas que ya no existen, copias de seguridad de entornos abandonados. Es el software zombi del módulo 2, en versión programada.
4 // Elegir la hora
El cuándo también importa, por dos motivos.
Para no crear picos. Si todas las tareas de todos los clientes se programan a las 00:00, los servidores tienen que dimensionarse para ese momento y pasar el resto del día infrautilizados, lo contrario de la proporcionalidad energética que viste en el módulo 2. Repartir las tareas a lo largo de la noche, o añadir un pequeño retraso aleatorio (jitter), aplana la carga. Y conviene evitar que una ejecución empiece antes de que acabe la anterior, porque se acumulan.
Para buscar la electricidad más limpia. Muchas tareas no tienen prisa: el informe tiene que estar listo por la mañana, pero da igual si se genera a la 1:00 o a las 5:00. Es la oportunidad perfecta para el desplazamiento en el tiempo del software consciente del carbono. Con la previsión de intensidad de la red eléctrica, la tarea puede lanzarse en la franja con más renovables. En España, con mucha solar, las horas centrales del día suelen ser más limpias que la noche, así que a veces lo más eficiente es cambiar la costumbre de ejecutarlo todo de madrugada.
Una tarea en segundo plano eficiente reacciona a eventos en lugar de preguntar, trabaja por lotes y sólo sobre lo que ha cambiado, y se ejecuta a una hora elegida con criterio. Y antes que todo eso, alguien se ha preguntado si sigue haciendo falta.