Tu sistema funciona bien. Hasta que todos llegan al mismo tiempo.
La plataforma responde rápido en condiciones normales. Los paneles de observabilidad no muestran alertas relevantes, las APIs mantienen una latencia aceptable y los usuarios completan sus operaciones sin incidentes. Sin embargo, llega una campaña comercial, un cierre de mes, la apertura de inscripciones o una notificación masiva, y el comportamiento cambia: aumentan los tiempos de respuesta, aparecen errores intermitentes, se acumulan tareas asíncronas y algunos procesos críticos dejan de completarse.
El problema no siempre es un error de desarrollo ni una caída total de infraestructura. Con frecuencia, es una diferencia entre estabilidad cotidiana y capacidad real bajo demanda concurrente. Una plataforma puede funcionar correctamente con el tráfico habitual y, aun así, no estar preparada para el momento en que una gran parte de sus usuarios intenta hacer algo al mismo tiempo.
Las pruebas de rendimiento permiten reducir esta incertidumbre antes de que el problema ocurra en producción. No se trata solo de “poner muchos usuarios” contra una API, sino de validar flujos de negocio, identificar cuellos de botella y tomar decisiones técnicas con evidencia.
El tráfico normal no demuestra que una plataforma tenga capacidad
Un sistema saludable en operación diaria demuestra que puede atender la carga que recibe habitualmente. No demuestra, por sí solo, que pueda soportar picos de concurrencia, cambios bruscos de demanda o procesos intensivos ejecutándose en paralelo.
Esto es especialmente relevante en plataformas SaaS, e-commerce y fintech, donde la demanda suele concentrarse en ventanas concretas:
- Una campaña promocional que dirige tráfico a un catálogo, carrito o checkout.
- El cierre de mes, cuando múltiples clientes consultan reportes, facturas o conciliaciones.
- El vencimiento de un plazo de pago o la apertura de una convocatoria.
- Una comunicación por correo, notificación push o mensajería que activa a muchos usuarios.
- Un proceso operativo que dispara sincronizaciones, importaciones o generación de documentos.
En estos escenarios, el riesgo no está únicamente en el número de solicitudes por segundo. También importa qué operaciones se ejecutan, cuánto duran, qué recursos comparten y qué dependencias externas intervienen.
Por ejemplo, una API de consulta puede escalar razonablemente bien si lee datos indexados y usa caché. Pero un flujo de compra, pago o creación de cuenta puede requerir validaciones, escrituras en varias tablas, llamadas a proveedores externos, publicación de eventos y generación de tareas posteriores. Dos flujos con un volumen de tráfico similar pueden tener impactos muy distintos sobre la plataforma.
Qué suele romperse cuando todos llegan al mismo tiempo
Los incidentes de rendimiento rara vez tienen una sola causa. A menudo, una parte del sistema se satura y provoca efectos en cadena sobre otros componentes. Un servicio lento puede ocupar conexiones, aumentar reintentos, generar más trabajo en colas y agotar recursos compartidos.
La base de datos se convierte en el cuello de botella
Es frecuente que el backend tenga varias instancias disponibles, pero que la base de datos no pueda procesar el patrón de lectura y escritura generado durante el pico. Algunas causas habituales son consultas sin índices adecuados, filtros poco selectivos, operaciones que bloquean registros, transacciones extensas o límites insuficientes en el pool de conexiones.
Escalar el número de réplicas de una API no resuelve necesariamente este problema. De hecho, puede empeorarlo si cada nueva instancia abre más conexiones o aumenta el volumen de consultas contra una dependencia ya saturada.
Los servicios dependientes responden más lento o aplican límites
Una operación puede depender de un proveedor de pagos, un sistema de identidad, un servicio de correo, una API de terceros o una plataforma de mensajería. Si esa dependencia degrada su respuesta, el servicio que la invoca puede acumular solicitudes en espera.
Sin límites de tiempo, circuit breakers, colas o mecanismos de degradación controlada, una dependencia lenta puede terminar afectando procesos que no tienen relación directa con ella.
Las colas crecen más rápido de lo que los consumidores procesan
En arquitecturas event-driven, desacoplar procesos mediante Kafka, colas o brokers puede proteger la experiencia síncrona del usuario. Sin embargo, la asincronía no elimina la necesidad de capacidad: desplaza parte de la carga.
Si los productores generan eventos a una velocidad mayor que la de los consumidores, aparece backlog. En algunos casos es aceptable procesar con retraso; en otros, como confirmaciones de pago, actualización de inventario o cálculos de riesgo, el retraso puede convertirse en un problema de negocio.
Los reintentos multiplican la carga
Cuando una API empieza a responder lento, clientes, gateways o servicios internos pueden reintentar solicitudes. Si estos reintentos no tienen límites, espera progresiva o idempotencia, una degradación inicial puede transformarse en una sobrecarga mayor.
El patrón es conocido: una dependencia se ralentiza, aumentan los timeouts, se disparan reintentos y la infraestructura recibe más trabajo justo cuando tiene menos capacidad disponible para procesarlo.
Una prueba de rendimiento útil empieza por el comportamiento de negocio
Una prueba de capacidad no debería construirse a partir de una única URL ni limitarse a enviar solicitudes idénticas contra un endpoint. Ese enfoque puede detectar ciertos límites técnicos, pero no representa necesariamente cómo utilizan la plataforma los usuarios reales.
El punto de partida debe ser una pregunta de negocio concreta: ¿qué debe poder hacer la plataforma durante el próximo evento de alta demanda?
Para responderla, conviene identificar los flujos críticos. En un e-commerce podrían ser búsqueda de productos, consulta de disponibilidad, carrito, checkout y confirmación de pedido. En una fintech, inicio de sesión, consulta de saldo, transferencias, validaciones y notificaciones. En un SaaS B2B, acceso al panel, carga de datos, generación de reportes y ejecución de procesos programados.
El perfil de carga debe representar una situación plausible
Un escenario útil considera que no todos los usuarios realizan la misma acción ni llegan de forma perfectamente uniforme. Puede haber una subida progresiva, una ráfaga provocada por una campaña o una combinación de operaciones de lectura y escritura.
También debe contemplar acciones que suelen pasar desapercibidas, como refrescos automáticos de interfaz, polling, consultas de filtros, carga de recursos estáticos, llamadas desde integraciones o tareas internas activadas por cada operación del usuario.
La calidad de los datos de prueba importa
Un entorno con pocos registros o datos excesivamente simples puede ocultar problemas que aparecerían con volúmenes más representativos. Consultar un catálogo reducido no ejerce la misma presión que buscar, filtrar y ordenar sobre un conjunto de datos realista. De la misma forma, probar escrituras sin restricciones, relaciones o reglas de validación puede producir resultados optimistas.
No siempre es posible replicar producción de manera exacta, pero el equipo debe documentar qué diferencias existen entre ambos entornos y cómo podrían afectar las conclusiones.
No basta con medir latencia: hay que entender cuándo el sistema deja de cumplir
Una prueba de rendimiento tiene valor cuando permite decidir si el sistema cumple sus expectativas operativas y de negocio bajo una carga determinada. Para ello, las métricas deben observarse en conjunto.
- Latencia: cuánto tarda una operación y cómo se comportan las respuestas lentas, no solo el promedio.
- Tasa de errores: respuestas fallidas, timeouts, validaciones inesperadas o errores de dependencias.
- Throughput: cuántas operaciones se completan realmente en un periodo, no solo cuántas se intentan enviar.
- Uso de recursos: CPU, memoria, conexiones, disco, red y límites de contenedores o nodos.
- Salud de dependencias: tiempo de respuesta de bases de datos, cachés, brokers, servicios externos y almacenamiento.
- Profundidad de colas y retraso de consumidores: especialmente importante en procesos asíncronos.
El promedio puede ocultar problemas importantes. Una API puede tener una latencia promedio aceptable mientras una proporción de solicitudes supera el tiempo tolerable para el usuario o termina en timeout. Por eso es útil analizar percentiles de latencia y correlacionarlos con trazas, logs y métricas de infraestructura.
La pregunta relevante no es solo “¿cuántas solicitudes soportó?”. Es también: ¿cuándo comenzó la degradación, qué componente se saturó primero y qué impacto tuvo en los flujos críticos?
Tipos de pruebas que ayudan a reducir el riesgo
No todas las pruebas de rendimiento buscan responder lo mismo. Elegir el tipo adecuado evita conclusiones incompletas y ayuda a preparar mejor una fecha de alta demanda.
Prueba de carga
Busca validar el comportamiento del sistema bajo una carga esperada o planificada. Es apropiada para comprobar si los flujos críticos cumplen los objetivos operativos durante un evento conocido, como una campaña, un cierre o una activación comercial.
Prueba de estrés
Aumenta la carga por encima de lo esperado para observar cómo falla la plataforma y si puede recuperarse. No pretende demostrar que el sistema funcionará indefinidamente bajo saturación, sino identificar límites, mecanismos de protección y comportamientos peligrosos.
Puede revelar, por ejemplo, si una saturación deja conexiones bloqueadas, si los pods se reinician sin recuperar tráfico correctamente o si la cola continúa creciendo después de que el pico termina.
Prueba de resistencia o duración
Evalúa el sistema durante un periodo prolongado. Resulta útil para detectar fugas de memoria, crecimiento progresivo de conexiones, acumulación de mensajes, degradación de cachés o tareas programadas que compiten por recursos con el tráfico de usuarios.
Prueba de picos
Simula aumentos abruptos de actividad. Es especialmente pertinente cuando una notificación, una venta limitada, una integración o un evento público puede generar una llegada masiva de usuarios en poco tiempo.
Estas pruebas no deben interpretarse de forma aislada. Una plataforma puede superar una prueba de carga gradual y fallar ante un pico repentino porque los mecanismos de autoescalado, calentamiento de caché, conexiones o aprovisionamiento no reaccionan con la suficiente rapidez.
Errores frecuentes al preparar capacidad para un evento de alta demanda
Muchas organizaciones invierten en infraestructura adicional antes de un evento, pero mantienen incertidumbre porque no han validado el comportamiento completo del sistema. Estos son algunos errores comunes.
- Probar solo un endpoint: no representa los flujos reales ni las dependencias involucradas en una operación completa.
- Usar un entorno demasiado distinto a producción: puede ocultar límites de red, configuración, datos, almacenamiento o recursos compartidos.
- Medir únicamente el backend: gateways, CDN, autenticación, bases de datos, colas y proveedores externos también forman parte de la experiencia.
- Escalar sin identificar el cuello de botella: agregar instancias puede no ayudar si el límite está en la base de datos, una API externa o una cola.
- Ignorar las operaciones asíncronas: una respuesta HTTP exitosa no garantiza que el proceso posterior se haya completado en el tiempo esperado.
- No definir criterios de aceptación: sin umbrales acordados, el equipo puede terminar una prueba sin saber si el resultado es suficiente.
- No planificar la degradación: cuando los recursos son limitados, conviene decidir qué funcionalidades pueden ralentizarse o posponerse para proteger las operaciones críticas.
También es importante evitar realizar pruebas agresivas sobre producción sin una evaluación explícita del riesgo. Dependiendo del sistema, una prueba mal ejecutada puede afectar usuarios reales, generar costos no previstos, activar controles antifraude o provocar limitaciones en servicios de terceros.
Cómo convertir las pruebas de capacidad en una práctica operativa
La preparación para un evento de alta demanda no debería depender de una prueba puntual hecha pocos días antes. Los mejores resultados aparecen cuando la capacidad se trata como una propiedad que se valida de forma recurrente, junto con la calidad, la seguridad y la confiabilidad.
Un enfoque pragmático puede comenzar con los flujos de mayor impacto y evolucionar de forma incremental:
- Identificar las operaciones cuyo fallo tendría mayor costo para usuarios y negocio.
- Definir expectativas verificables de latencia, errores, procesamiento asíncrono y recuperación.
- Crear escenarios reproducibles con datos y patrones de uso representativos.
- Instrumentar métricas, logs y trazas antes de ejecutar la prueba.
- Registrar el primer componente que se degrada y la causa técnica probable.
- Priorizar correcciones según impacto: consultas, caché, concurrencia, límites, colas, timeouts o arquitectura.
- Repetir la prueba después de los cambios para verificar que la mejora no desplazó el problema a otra dependencia.
En sistemas desplegados sobre cloud o Kubernetes, este proceso también permite validar decisiones operativas: límites y solicitudes de recursos, comportamiento del autoescalado, capacidad de los nodos, pools de conexiones, políticas de reintento y observabilidad de servicios distribuidos. La configuración puede ser técnicamente válida y aun así no responder como se espera frente a una carga realista.
Para equipos que aún no tienen esta práctica consolidada, una revisión técnica externa o una capacitación enfocada en performance puede ayudar a diseñar escenarios, interpretar resultados y establecer un plan de mejora sin convertir las pruebas en un ejercicio aislado.
La capacidad no se asume: se valida antes del pico
Que una plataforma funcione bien todos los días es una señal positiva, pero no es evidencia suficiente de que resistirá una demanda concentrada. Los eventos de alta concurrencia exponen límites que permanecen invisibles durante la operación habitual: consultas costosas, dependencias lentas, colas sin capacidad suficiente, configuraciones de escalado incompletas y mecanismos de reintento que amplifican la carga.
Una estrategia de pruebas de rendimiento bien planteada conecta el riesgo técnico con una pregunta de negocio: qué operaciones deben seguir funcionando cuando la demanda aumenta. A partir de esa respuesta, el equipo puede definir escenarios, medir el comportamiento end-to-end, encontrar cuellos de botella y preparar mecanismos de protección y recuperación.
Antes del próximo evento de alta demanda, valida cuánto tráfico soporta realmente tu plataforma. En Mentores Tech podemos acompañar a tu equipo en la evaluación de performance y estabilidad, desde el diseño de escenarios hasta la interpretación técnica de los resultados y la priorización de mejoras.
