La concurrencia y el paralelismo surgieron para responder a demandas de cálculo y disponibilidad cada vez mayores. No son un capricho teórico: son la base para seguir sirviendo usuarios, procesar datos masivos y reducir tiempos de espera cuando un enfoque secuencial deja de ser suficiente.
Este tema repasa la evolución del hardware y las cargas de trabajo, y muestra en qué escenarios estos enfoques dejan de ser opcionales y se vuelven obligatorios.
A medida que crecen los usuarios, los datos y la complejidad de los sistemas, también crece la exigencia de responder rápido y aprovechar mejor el hardware. La concurrencia permite que un sistema siga atendiendo tareas pendientes sin bloquearse; el paralelismo permite acelerar el procesamiento dividiéndolo en partes simultáneas.
La digitalización multiplicó el volumen de peticiones y datos. Sitios con millones de visitas, sensores generando flujos continuos y análisis de grandes conjuntos de datos exigen que las aplicaciones sigan funcionando bajo carga. La arquitectura concurrente evita que un trabajo lento (como acceder a disco o red) detenga a los demás.
La mejora de frecuencia en CPUs tradicionales se frenó por límites físicos (calor y consumo). La Ley de Moore ya no se traduce solo en megahercios. Un núcleo puede ejecutar más rápido hasta cierto punto; después, necesitamos dividir el trabajo o quedaremos atados a un techo de rendimiento.
Los fabricantes respondieron incorporando varios núcleos por chip. Este diseño ofrece paralelismo de hardware, pero solo se aprovecha si el software está preparado. Programas estrictamente secuenciales dejan núcleos ociosos; un diseño concurrente puede repartir tareas y un diseño paralelo puede dividir cálculos pesados.
Una tarea I/O-bound pasa la mayor parte del tiempo esperando entrada/salida (red, disco, base de datos). La concurrencia permite que, mientras una tarea espera, otra continúe avanzando. Una tarea CPU-bound consume ciclos de CPU; el paralelismo permite dividirla entre núcleos para terminar antes. Identificar el tipo de carga es clave para decidir qué enfoque usar.
En todos estos casos, diseñar de forma concurrente no es opcional: es el único modo de mantener la disponibilidad y la velocidad percibida por el usuario.