En el desarrollo de aplicaciones modernas, especialmente aquellas que dependen de múltiples fuentes de datos externas, la gestión correcta de promesas concurrentes puede marcar la diferencia entre un sistema robusto y una experiencia frustrante para el usuario. Es habitual encontrarse con equipos que utilizan Promise.all para lanzar varias peticiones simultáneas, sin detenerse a pensar qué ocurre cuando una de ellas falla. La respuesta es simple: todo el bloque se rechaza. En escenarios donde el fallo parcial es aceptable, esta decisión puede provocar que una única API lenta o un error temporal derribe completamente un dashboard, una página de inicio o incluso un flujo crítico de negocio.
Para afrontar esta realidad, JavaScript ofrece tres alternativas que conviene conocer a fondo: Promise.allSettled, Promise.any y Promise.race. Cada una resuelve un problema específico de concurrencia y tolerancia a fallos, y elegir la adecuada es una competencia esencial para desarrolladores que buscan construir aplicaciones a medida con alta disponibilidad.
Imaginemos un panel de indicadores corporativos que necesita mostrar ventas, métricas de usuario, alertas de ciberseguridad y datos de inventario. Si utilizamos Promise.all y la API de alertas responde con un error 500, el resto de los widgets no recibirán datos. El usuario verá una pantalla en blanco o un mensaje genérico de error. Este comportamiento es incoherente con la expectativa de que cada componente funcione de forma independiente. Aquí entra en juego Promise.allSettled: espera a que todas las promesas terminen —ya sea con éxito o con fallo— y devuelve un array con el estado de cada una. El desarrollador puede entonces tratar cada resultado por separado, mostrando el widget correcto o una indicación de error parcial. Este patrón es especialmente útil en soluciones de servicios inteligencia de negocio y Power BI, donde un panel debe seguir siendo operativo incluso cuando alguna fuente de datos no responde.
Otro caso de uso frecuente aparece en entornos con múltiples servidores o CDNs. Supongamos que necesitamos obtener la respuesta más rápida entre varios endpoints duplicados para garantizar una baja latencia en la carga de recursos críticos, como modelos de inteligencia artificial o datos para agentes IA. Promise.any es la herramienta indicada: resuelve con la primera promesa que se cumple satisfactoriamente, ignorando los rechazos previos. Solo si todas fallan se produce un error agregado. Este enfoque es ideal en arquitecturas multirregión con servicios cloud aws y azure, donde se busca maximizar la disponibilidad sin penalizar el rendimiento. Por el contrario, Promise.race se dispara con la primera promesa que se complete —sea éxito o error— y se emplea típicamente para implementar timeouts. Por ejemplo, al lanzar una petición a un servicio externo, podemos combinarla con una promesa que rechace tras un tiempo límite, protegiendo así la experiencia del usuario y evitando esperas indefinidas. En proyectos de ciberseguridad y pentesting, este patrón ayuda a controlar la duración de escaneos o pruebas de penetración.
No obstante, Promise.all no debe ser demonizada. Sigue siendo la elección correcta cuando se requiere atomicidad: por ejemplo, al realizar una operación que debe escribir en tres bases de datos distintas y cuyo fallo debe provocar un rollback completo. En transacciones financieras o en la actualización de estados críticos dentro de un software a medida, la coherencia global es más importante que la disponibilidad parcial.
La clave está en preguntarse: ¿puedo aceptar que una parte falle sin que el resto se vea afectado? Si la respuesta es sí, Promise.allSettled o Promise.any son tus aliadas. Si necesitas la primera respuesta —sin importar su naturaleza— utiliza Promise.race combinado con mecanismos de cancelación como AbortController. En Q2BSTUDIO, desarrollamos ia para empresas y aplicaciones que integran estas técnicas para ofrecer sistemas resilientes, escalables y centrados en el usuario. La elección del método de concurrencia no es un detalle menor: es una decisión de diseño que impacta directamente en la experiencia final y en la robustez del producto. Conocer a fondo las cuatro promesas y aplicarlas según el contexto permite construir aplicaciones que se adaptan a entornos reales, donde los fallos no son excepciones, sino parte del paisaje.
