Performance optimization: Optimización del rendimiento

El patrón suele ser el mismo. La startup por fin encuentra encaje con el mercado, entra más tráfico, crecen las integraciones y el equipo celebra que el producto ya importa. Dos semanas después, soporte abre incidencias por lentitud, ventas empieza a oír objeciones sobre la experiencia y los desarrolladores discuten si el problema está en la base de datos, en la API, en el frontend o en la infraestructura.

‍

He visto ese punto de inflexión varias veces. La mala noticia es que la lentitud rara vez viene de un solo sitio. La buena es que casi siempre deja señales claras si el equipo sabe medir, interpretar y priorizar. Ahí empieza el trabajo real de performance optimization.

‍

Lo importante no es solo arreglar milisegundos. Es proteger retención, evitar que el coste de adquisición se desperdicie en una primera experiencia mediocre y impedir que cada nuevo cliente aumente el estrés operativo del equipo. La optimización del rendimiento no es una tarea de limpieza técnica. Es una disciplina de producto, arquitectura y contratación.

‍

Cuando la velocidad se convierte en tu principal producto

‍

Al principio, casi cualquier arquitectura aguanta. Un monolito razonable, una base de datos bien cuidada y algo de caché suelen bastar para lanzar y vender. El problema llega cuando el sistema deja de operar en condiciones cómodas. Empiezan las colas, las consultas se pisan entre sí, el frontend descarga más JavaScript del que necesita y cada release añade una pequeña penalización que nadie nota hasta que el conjunto pesa demasiado.

‍

El usuario no distingue si el cuello de botella está en PostgreSQL, en Redis, en Nginx o en una función mal diseñada. Solo percibe que el producto responde tarde. Y cuando eso ocurre en un momento clave, onboarding, checkout, búsqueda, generación de informes o inferencia de un modelo, la velocidad pasa a formar parte del propio producto.

‍

Lo que cambia cuando la carga deja de ser teórica

‍

En una fase temprana, muchos equipos optimizan por intuición. Comprimen assets, añaden un índice, cambian una librería y esperan mejora. A veces funciona. A menudo solo mueve el problema a otro sitio.

‍

Un CTO serio cambia el enfoque en cuanto aparecen los primeros síntomas repetidos. Ya no pregunta “qué podemos tunear”, sino “qué parte del sistema limita el negocio ahora mismo”. Son preguntas distintas, y llevan a decisiones distintas.

‍

La mayoría de los problemas de rendimiento graves no nacen por falta de herramientas. Nacen por falta de diagnóstico y por aceptar demasiada complejidad sin un criterio operativo claro.

‍

Cuando una aplicación empieza a sentirse pesada, hay cuatro capas que suelo revisar sin perder tiempo:

• Experiencia de usuario: tiempos de respuesta en los flujos que generan conversión o activación.
• Aplicación y base de datos: rutas calientes, consultas repetitivas, serialización, locking y uso de caché.
• Infraestructura: límites de CPU, memoria, red, auto-scaling mal calibrado y saturación silenciosa.
• Cargas de ML: inferencia lenta, pipelines de datos desequilibrados o hardware local desaprovechado.

‍

El error de gestión más caro

‍

Muchas startups creen que el reto es técnico cuando en realidad también es organizativo. Un equipo puede tener Prometheus, Grafana, Jaeger, Redis, Kafka y Cloudflare, y seguir tomando malas decisiones si nadie sabe priorizar trade-offs. La herramienta no sustituye al criterio.

‍

Por eso el rendimiento también es un problema de talento. Si contratas a alguien que solo sabe “hacerlo más rápido”, obtendrás optimizaciones locales. Si contratas a alguien que entiende sistemas, coste, latencia y riesgo operativo, tendrás una práctica continua de mejora. Esa diferencia se nota mucho más que cualquier benchmark aislado.

‍

El framework de diagnóstico: Dejar de adivinar y empezar a medir

‍

El patrón se repite. El equipo recibe quejas por lentitud, alguien propone añadir caché, otro pide subir instancias y nadie puede responder una pregunta básica: qué parte del sistema está frenando una métrica de negocio concreta. Sin esa respuesta, optimizar rendimiento se convierte en una secuencia cara de cambios a prueba y error.

‍

El framework útil no empieza por herramientas. Empieza por una disciplina de diagnóstico. Primero se define el flujo que afecta ingresos, activación o retención. Luego se fija el límite aceptable para ese flujo. Después se instrumenta lo suficiente para aislar la causa. Solo entonces tiene sentido tocar código, consultas o infraestructura.

‍

He visto equipos perder semanas mirando dashboards impecables que no servían para decidir nada. Medían CPU, memoria y latencia media, pero no sabían cuánto tardaba el checkout bajo carga real, qué consulta degradaba la búsqueda o si el problema nacía en la API, en la base de datos o en una dependencia externa. Instrumentar mucho no equivale a diagnosticar bien.

‍

Tres decisiones antes de abrir Grafana

‍

La primera decisión es qué flujo merece atención inmediata. No todos los endpoints pesan igual. Si el registro convierte, si una búsqueda sostiene el catálogo o si una inferencia decide la experiencia principal, ese flujo debe tener prioridad técnica y visibilidad operativa.

‍

La segunda es qué umbral dispara una intervención. Un sistema sin SLOs claros genera alertas decorativas. Latencia, tasa de error, saturación y throughput deben tener límites explícitos y asociados a impacto real.

‍

La tercera es qué evidencia exige el equipo para tocar producción. Una subida puntual de CPU no basta. Hace falta correlacionar síntoma, ruta afectada, dependencia implicada y coste de la intervención.

‍

Aquí conviene separar tres prácticas que muchos equipos mezclan:

• Monitorización: sirve para ver el estado general del sistema y detectar degradaciones sostenidas. Prometheus y Grafana siguen funcionando bien para esto.
• Profiling: sirve para encontrar dónde se va el tiempo o la memoria dentro de un proceso concreto.
• Tracing: sirve para seguir una petición entre servicios, colas y terceros. Jaeger encaja bien en arquitecturas distribuidas.

‍

También hay una cuarta capa que suele quedar fuera del diagnóstico inicial. El diseño de la interfaz entre clientes y backend. En más de una auditoría, el problema no era la base de datos, sino una API que obligaba a hacer demasiadas llamadas o devolvía payloads innecesarios. Por eso conviene revisar decisiones de contrato desde el principio, por ejemplo en esta comparación entre REST y GraphQL para elegir el patrón de API según el caso.

‍

Leer señales en conjunto

‍

La analogía con la variabilidad frecuencia cardíaca sí aporta algo aquí. Una señal aislada rara vez explica el estado completo. En sistemas ocurre lo mismo. CPU alta puede ser tráfico legítimo, una consulta mal indexada, serialización ineficiente o un retry storm. La diferencia la marca el contexto.

‍

Por eso conviene leer métricas en grupo. Latencia p95 junto con tasa de error. Saturación de conexiones junto con tiempos de consulta. Longitud de cola junto con tiempo de procesamiento. Ese cruce evita decisiones impulsivas, como escalar instancias cuando el cuello real está en locking o en un servicio externo.

‍

Regla práctica: si el equipo no puede explicar qué cambió, dónde cambió y por qué ese cambio degradó una métrica, todavía no tiene un diagnóstico. Tiene observación parcial.

‍

El rendimiento también expone si estás contratando bien

‍

Aquí aparece un ángulo que muchos artículos técnicos omiten. Un mal proceso de diagnóstico casi siempre revela un problema de talento, no solo de arquitectura. Si la persona responsable propone soluciones antes de formular hipótesis, no sabe operar sistemas bajo presión. Si solo habla de herramientas, pero no de prioridades de negocio, tampoco.

‍

Para evaluar a un candidato que vaya a tocar rendimiento, uso un checklist simple:

• ¿Sabe traducir una queja difusa en una hipótesis medible?
• ¿Distingue entre síntoma, causa raíz y efecto colateral?
• ¿Puede explicar el coste de cada mejora en complejidad, infraestructura y riesgo de regresión?
• ¿Prioriza por impacto en negocio antes que por preferencia técnica?
• ¿Pide trazas, perfiles y datos de carga reales antes de proponer cambios?
• ¿Entiende que una mejora local puede empeorar el sistema completo?

‍

Ese filtro importa porque el rendimiento no se arregla con héroes de madrugada. Se mejora con ingeniería disciplinada y criterio para decidir dónde actuar y dónde no.

‍

Un checklist mínimo que sí sirve

• Define SLOs ligados al negocio. No métricas de vanidad.
• Instrumenta rutas críticas primero. El detalle fino va donde hay impacto.
• Correlaciona métricas, trazas y logs. Una sola señal lleva a errores.
• Prueba escenarios parecidos a producción. La carga uniforme rara vez representa usuarios reales.
• Exige evidencia antes de optimizar. Cambiar sin aislar causa raíz introduce deuda.
• Usa el diagnóstico para evaluar talento. Quien mide bien suele decidir mejor.

‍

Técnicas de optimización en la aplicación y la base de datos

‍

Un equipo detecta latencia, abre el dashboard y salta demasiado rápido a una solución favorita. Más CPU, más réplicas, más caché. Ese reflejo cuesta dinero y rara vez corrige la causa raíz. En esta fase, la diferencia entre un equipo maduro y uno caro está en elegir la intervención que reduce tiempo de respuesta sin disparar complejidad operativa.

‍

Mi criterio es simple. Empieza por la capa donde el equipo puede cambiar algo esta semana, medir el efecto y revertir si hace falta. En la práctica, eso suele significar aplicación, consultas, caché y contratos de API antes de rediseñar media plataforma. Un TTFB sano importa porque condensa varias decisiones a la vez. Backend, acceso a datos, red y entrega de contenido.

‍

Caché con política, no con fe

‍

Añadir Redis sin definir qué se guarda, cuánto vive y cómo se invalida suele crear un sistema más frágil que rápido. La caché funciona bien cuando responde a una pregunta concreta: reducir lecturas repetidas, absorber picos o evitar cálculos costosos.

‍

Caché en memoria local

‍

Encaja bien en datos calientes, baratos de recalcular y con tolerancia a pequeñas diferencias entre instancias. La latencia baja mucho porque no hay salto de red y la implementación suele ser directa.

‍

El problema aparece al escalar horizontalmente. Cada réplica conserva su propio estado y la invalidación empieza a depender de disciplina de equipo, no de diseño. Si el dato afecta precios, stock, permisos o cualquier decisión sensible, esa estrategia se vuelve peligrosa muy rápido.

‍

Caché distribuida

‍

Con Redis o Memcached el estado compartido deja de depender de cada proceso. Eso ayuda en sesiones, rate limiting, agregados temporales o resultados costosos que varias instancias necesitan reutilizar. A cambio, suben la complejidad operativa, el coste de red y los fallos posibles.

‍

La decisión correcta depende menos de la herramienta y más de la tolerancia al dato desactualizado. Si un candidato para backend no puede explicar TTL, invalidación y estrategia ante cache stampede, todavía no está listo para optimizar sistemas con tráfico real. Esa es una buena pregunta de entrevista porque revela criterio, no memoria.

‍

Procesamiento asíncrono y contratos que no castigan al usuario

‍

Muchas APIs se vuelven lentas por mezclar trabajo interactivo con trabajo interno. El usuario pide una acción simple y la petición intenta enviar correos, recalcular métricas, hablar con terceros, generar archivos y dejar todo persistido antes de responder. Ese diseño bloquea el camino crítico con tareas que el usuario no necesita ver al instante.

‍

Mover parte del flujo a colas como RabbitMQ o Kafka suele mejorar tiempos de respuesta y estabilidad bajo carga. Pero introduce otras obligaciones: idempotencia, reintentos, dead-letter queues, trazabilidad y manejo de consistencia eventual. El trade-off merece la pena cuando el equipo sabe operar ese modelo. Si no, solo cambia latencia visible por errores difíciles de rastrear.

‍

El contrato de la API también pesa. Un diseño pobre obliga al cliente a pedir de más, repetir llamadas o combinar respuestas de forma ineficiente. Si el equipo está evaluando ese punto, esta comparación entre REST y GraphQL según el tipo de acceso a datos sirve para discutir payloads, control de consultas y complejidad operativa con algo más de criterio que una preferencia de framework.

‍

Base de datos. El lugar donde se gana o se pierde el día

‍

Muchos equipos culpan al ORM o a la infraestructura antes de leer un plan de ejecución. Ese orden es un error. Una consulta lenta puede venir de un índice ausente, sí, pero también de un filtro mal planteado, un join que multiplica cardinalidad, lecturas innecesarias o paginaciones diseñadas sin pensar en volumen.

‍

Una consulta lenta casi nunca se corrige bien afinando el ORM. Se corrige entendiendo cómo ejecuta la base de datos.

‍

Hay tres prácticas que sigo revisando en cualquier sistema con problemas de rendimiento:

• Leer EXPLAIN con disciplina. No para confirmar una intuición, sino para ver coste, cardinalidad estimada y recorrido real.
• Usar connection pooling bien configurado. Un pool pequeño estrangula throughput. Uno grande degrada la propia base de datos.
• Separar lectura y escritura solo cuando el patrón lo pide. Las réplicas ayudan en cargas de lectura intensas, pero añaden retraso de replicación, más observabilidad y decisiones de enrutado que el equipo debe dominar.

‍

Aquí también aparece el ángulo de talento. En entrevistas, conviene pedir a la persona candidata que explique qué haría ante una consulta que pasa de 40 ms a 900 ms con diez veces más datos. Quien responde “pondría un índice” sin pedir el plan, el patrón de acceso y la distribución de datos probablemente optimizará por reflejo, no por diagnóstico.

‍

El backend no siempre es el culpable

‍

He visto APIs responder en tiempos razonables mientras la experiencia seguía siendo mala por culpa del navegador. Bundles pesados, hidratación agresiva, render bloqueado por JavaScript y dependencias que llegan demasiado pronto convierten una respuesta correcta en una interfaz lenta.

‍

La consecuencia práctica es clara. Optimizar rendimiento exige revisar el recorrido completo de la petición hasta la interacción. Si el equipo que contratas solo sabe hablar de SQL o solo sabe hablar de Lighthouse, te deja ciego en la mitad del problema. El perfil útil para una startup o una scaleup entiende dónde termina su capa y cómo sus decisiones empujan latencia al resto del sistema.

‍

Escalando la infraestructura y optimizando modelos de ML

‍

Hay un momento en el que la aplicación deja de ser el principal límite y la conversación baja un nivel. Infraestructura, red, almacenamiento y hardware. Ahí se toman decisiones que no siempre lucen en demos, pero definen si el sistema escala con control o si cada pico de carga se convierte en una urgencia.

‍

‍

En infraestructura general, mi criterio es conservador. Antes de subir gasto cloud, revisa si el servicio está mal dimensionado, si el auto-scaling reacciona tarde o si la distribución de carga tiene puntos ciegos. Elegir una instancia pensada para CPU cuando el cuello está en memoria solo compra frustración más cara.

‍

Escalar sin pagar dos veces

‍

Herramientas como Cloudflare o Fastly resuelven bien la entrega de activos y parte de la presión sobre origen. Kubernetes ayuda, pero no arregla una arquitectura confusa. Auto-scaling también ayuda, pero solo si las señales que lo gobiernan representan carga real y no ruido.

‍

Cuando el equipo no tiene claro qué hace un perfil de plataforma o quién debe liderar estas decisiones, conviene aterrizar responsabilidades. Esta explicación sobre qué hace un ingeniero DevOps sirve para separar automatización, operación, fiabilidad y escalabilidad, que muchas empresas meten erróneamente en la misma caja.

‍

ML en producción tiene cuellos de botella distintos

‍

Los sistemas de ML fallan de otra forma. Puedes tener una API bien optimizada y aun así sufrir tiempos pobres porque el pipeline de features llega tarde, la GPU está infrautilizada o el modelo carga más memoria de la que conviene para inferencia en tiempo real.

‍

Aquí los equipos cometen dos errores habituales:

• Mirar solo métricas clásicas de backend: latencia media, CPU general, memoria agregada.
• Ignorar los límites físicos del hardware local: temperatura, disipación, estabilidad eléctrica y throughput efectivo de disco.

‍

El ángulo más ignorado es el estrangulamiento térmico. Durante compilación intensiva o entrenamiento de IA, CPUs y GPUs pueden perder hasta un 20-30% de rendimiento máximo sin que DevOps lo detecte en métricas estándar, según esta referencia sobre thermal throttling en cargas de IA y compilación. Para startups españolas con hardware propio, el 45% de los retrasos en despliegues se atribuyen a limitaciones físicas no monitorizadas, en la misma fuente.

‍

Si ejecutas ML sobre hardware propio y no vigilas temperatura, consumo y estabilidad, estás operando a ciegas aunque tus dashboards de aplicación estén impecables.

‍

Lo que casi nadie revisa en sedes técnicas

‍

En empresas con infraestructura híbrida propia hay un detalle todavía más olvidado. El diseño energético. En España, errores de ±10° en la inclinación de paneles solares pueden generar pérdidas del 2-3%, y una mala orientación sur puede elevarlas hasta el 15%, como recoge esta explicación sobre inclinación y orientación de paneles solares. No es una discusión habitual en ingeniería de software, pero sí importa cuando una scaleup sostiene parte de su capacidad técnica en instalaciones propias.

No todos los CTOs tendrán que entrar ahí. Pero quien opera training local, edge compute o laboratorios de IA con hardware sensible debería tratar energía y refrigeración como parte del rendimiento, no como un tema aparte de facilities.

‍

El talento detrás del rendimiento: Cómo contratar al perfil correcto

‍

La mayoría de empresas intenta resolver problemas de rendimiento comprando herramientas. Mi experiencia dice otra cosa. El rendimiento mejora de forma sostenida cuando hay personas capaces de diagnosticar, priorizar y ejecutar con criterio. Sin eso, el stack se llena de productos y el sistema sigue lento.

‍

El error más común en hiring es buscar un perfil genérico que “sepa de backend y algo de cloud”. Eso sirve para mantener el sistema. No siempre sirve para rediseñarlo bajo presión real.

‍

Qué perfiles resuelven problemas distintos

‍

No hace falta fichar todos estos roles a la vez, pero sí entender qué aporta cada uno:

• Ingeniero de rendimiento: sabe perfilar, medir, reproducir carga, leer cuellos de botella y validar mejoras sin autoengaño.
• SRE o perfil de fiabilidad: convierte rendimiento en objetivos operativos, alertas útiles y disciplina de operación.
• Especialista en bases de datos: evita que el equipo haga tuning cosmético sobre consultas mal diseñadas.
• Ingeniero de MLOps: traduce necesidades de modelos a pipelines reproducibles y sistemas de inferencia operables.
• Arquitecto de datos: define flujos y estructuras que evitan degradación a medida que crecen volumen y complejidad. Si ese rol te genera dudas, esta explicación sobre arquitecto de datos aclara bien dónde acaba el trabajo del data engineer y dónde empieza la responsabilidad arquitectónica.

‍

Cómo distinguir experiencia real de discurso bonito

‍

En entrevistas técnicas, no busco respuestas académicas. Busco memoria operativa. Quiero saber qué hizo la persona cuando el sistema falló de verdad.

‍

Estas preguntas filtran mejor que una lista de buzzwords:

1. Háblame de una degradación bajo carga. Qué señales viste primero, qué hipótesis descartaste y qué métrica te dio la pista correcta.
2. Cuándo eliges caché local y cuándo distribuida. Si la respuesta no menciona invalidación, consistencia y coste operativo, falta experiencia.
3. Qué revisarías en una consulta lenta antes de añadir índices.
4. Qué métricas vigilarías en un servicio de inferencia de modelos.
5. Cuándo pasarías trabajo a una cola y qué problemas introduces al hacerlo.
6. Cómo decides si un problema está en código, base de datos o infraestructura.

‍

También hago una prueba menos obvia. Pido al candidato que describa una optimización que decidió no hacer. Los buenos ingenieros no solo saben acelerar sistemas. Saben cuándo una mejora no compensa la complejidad que añade.

‍

Un candidato fuerte habla de trade-offs, no de trucos. Explica coste de mantenimiento, riesgo de regresión y efecto en la operación diaria.

‍

Señales de alerta en entrevistas

‍

Hay respuestas que me hacen frenar rápido:

• Todo se arregla con microservicios: mala señal. Puede aumentar latencia y complejidad.
• Siempre hay que meter Redis: mala señal. La caché no compensa un modelo de datos roto.
• Nunca he tenido problemas con observabilidad: mala señal. O no ha operado sistemas serios, o no los ha mirado a fondo.
• Optimicé muchísimo el sistema, pero no recuerda cómo lo midió: señal definitiva de humo.

‍

Presupuestar bien el talento

‍

Si la empresa quiere resolver rendimiento en sistemas con IA, también tiene que asumir el mercado salarial real. En España, para 2026, el salario medio de un Ingeniero de Machine Learning se sitúa entre 51.000 € y 65.000 € anuales, con perfiles sénior por encima de 77.552 €, según esta referencia sobre salarios de ingeniero de machine learning en España. Un AI/LLM Developer senior cobra entre 55.000 € y 75.000 €, y los perfiles especializados en MLOps o arquitectura de IA pueden superar los 90.000 €, según la misma fuente.

‍

Eso no significa que siempre necesites el perfil más caro. Significa que contratar por debajo del mercado para un problema crítico suele alargar el problema, no abaratarlo.

‍

Checklist corto para evaluar candidatos de rendimiento

• Diagnóstico: puede explicar una metodología, no solo herramientas.
• Priorización: distingue entre cuello de botella principal y ruido secundario.
• Base de datos: sabe leer planes de ejecución y hablar de pooling, locking y réplicas.
• Aplicación: entiende colas, caché, serialización y contratos de API.
• Infraestructura: conoce límites de auto-scaling, CDN y dimensionamiento.
• ML si aplica: vigila inferencia, carga de datos, uso de GPU y operación.
• Comunicación: convierte métricas en decisiones de negocio comprensibles.

‍

Conclusión: Integrando la optimización en la cultura de tu equipo

‍

La optimización del rendimiento no termina cuando baja una métrica problemática. Termina cuando el equipo deja de crear los mismos problemas una y otra vez. Por eso prefiero hablar de cultura de rendimiento y no de proyecto de tuning.

‍

Un equipo maduro introduce performance optimization desde diseño. Piensa en payloads antes de abrir endpoints, en planes de ejecución antes de escribir consultas complejas, en latencia antes de encadenar servicios y en operación antes de meter nuevas piezas en producción. Ese hábito evita más incendios que cualquier sprint reactivo.

‍

Tres decisiones que cambian el resultado

• Mide antes de tocar: sin marco de diagnóstico, la optimización es intuición disfrazada de trabajo técnico.
• Ataca el cuello correcto: no todo problema visible está en la capa que más se queja.
• Contrata para criterio, no para keywords: el rendimiento sostenido depende más de quién decide que de qué herramienta compras.

‍

También conviene ampliar la mirada. La lógica es la misma dentro y fuera del producto. Quien optimiza una plataforma debería entender que pequeñas fricciones acumuladas destruyen conversión en cualquier canal digital. Por eso me parece útil revisar ejemplos de otros entornos, como estos servicios de MONEYMAKER para Mercado Libre, donde la optimización de fichas y tiempos de respuesta también impacta directamente en rendimiento comercial. Cambia el contexto, no cambia la disciplina: medir, ajustar y repetir.

‍

El mejor sistema no es el que corre más rápido en un benchmark. Es el que mantiene una experiencia estable mientras el negocio crece y el equipo sigue pudiendo operar con calma.

‍

Si tu empresa ya siente esa tensión, no necesitas otra lista genérica de buenas prácticas. Necesitas diagnóstico serio, prioridades claras y el talento adecuado para sostener la mejora en el tiempo.

‍

Si estás contratando perfiles que puedan resolver problemas reales de rendimiento, escalabilidad, datos o IA, Kulturo ayuda a identificar y cerrar ese talento técnico con foco en startups y scaleups en España.