Cuando empecé como desarrollador junior pensaba que lo más importante era escribir buen código.
Con los años me di cuenta de que muchas de las lecciones más importantes no tienen que ver con escribir código elegante, sino con cómo se comportan los sistemas en producción.
Hace poco trabajé en una aplicación con unos 40.000 usuarios registrados y picos de 5.000–6.000 usuarios concurrentes. Ese proyecto me recordó varias lecciones que me habría gustado entender mucho antes en mi carrera.
Estas son algunas de ellas.
1. El código simple casi siempre es mejor
Cuando eres junior es fácil caer en la tentación de escribir código complejo para demostrar que sabes lo que haces.
En este proyecto, al revisar algunos servicios vimos funciones muy largas que mezclaban:
- lógica de negocio
- acceso a base de datos
- validaciones
- llamadas a otros servicios
Funcionaban, pero eran difíciles de entender y más aún de mantener.
Durante la refactorización dividimos esas piezas en funciones mucho más pequeñas y claras. El comportamiento no cambió, pero el código se volvió mucho más fácil de mantener y depurar.
La lección fue clara: en producción, el código que gana no es el más ingenioso, sino el más fácil de entender para el siguiente desarrollador que tenga que tocarlo.
2. La base de datos suele ser el verdadero cuello de botella
Cuando algo va lento en una aplicación, muchas veces pensamos que el problema está en el lenguaje o en el framework.
Pero en la práctica, el problema suele estar en la base de datos:
- queries mal diseñadas
- falta de índices
- demasiadas consultas
- mala gestión de conexiones
No en el lenguaje.
En este proyecto la aplicación estaba desarrollada con Node.js y Express.js, usando TypeORM como ORM.
Después del despliegue empezamos a ver que el servidor se bloqueaba durante algunos picos de tráfico.
Investigando el problema descubrimos que las conexiones con la base de datos no se cerraban correctamente. Muchas quedaban en estado standby, acumulándose hasta saturar la máquina.
Parte del problema venía de que decidimos usar transacciones en muchos casos de uso para garantizar la integridad de los datos. La decisión era razonable, pero la gestión de esas transacciones no estaba bien controlada.
En varios puntos de la aplicación las conexiones permanecían abiertas más tiempo del necesario, y bajo carga eso terminaba colapsando la base de datos.
La solución pasó por:
- refactorizar algunos puntos críticos
- mejorar la indexación de la base de datos
- reducir el uso innecesario de transacciones
- revisar cómo se gestionaban las conexiones
Después de esos cambios el sistema empezó a comportarse mucho mejor bajo carga.
3. Los logs son más importantes de lo que parece
Cuando el problema apareció en producción, lo primero que intentamos fue entender qué estaba pasando.
El problema es que no teníamos suficiente información en los logs.
Sabíamos que el servidor se saturaba, pero no exactamente:
- qué endpoints estaban generando más carga
- qué consultas tardaban más
- en qué punto del flujo se quedaban abiertas las transacciones
Tuvimos que mejorar bastante el sistema de logging para poder entender realmente el comportamiento del sistema.
Después de añadir logs más detallados fue mucho más fácil detectar los puntos donde las conexiones no se liberaban correctamente.
Una de las lecciones más claras fue esta:
Un sistema sin buenos logs es un sistema muy difícil de operar en producción.
4. No todo debería ejecutarse dentro de una petición HTTP
Otro problema que detectamos fue que algunas operaciones relativamente pesadas se ejecutaban dentro de la petición del usuario.
Por ejemplo:
- generación de ciertos reportes
- algunos procesos de sincronización de datos
- operaciones que abrían varias consultas consecutivas
Cuando el tráfico aumentaba, esas operaciones bloqueaban recursos durante demasiado tiempo.
La solución fue mover varios de esos procesos a colas de trabajo en segundo plano, de modo que la petición del usuario pudiera terminar rápido mientras el trabajo pesado se procesaba de forma asíncrona.
El resultado fue una reducción bastante notable en el tiempo de respuesta de algunos endpoints.
5. Los problemas reales casi nunca son solo técnicos
Al analizar el problema nos dimos cuenta de que parte del problema no era técnico, sino de proceso.
Por ejemplo:
- algunas decisiones de arquitectura se tomaron muy rápido
- no se había probado suficientemente el comportamiento bajo carga
- varias piezas del sistema evolucionaron de forma independiente
Nada de esto es raro en proyectos reales, pero demuestra algo importante:
muchos problemas en software no vienen del código, sino de cómo se toman las decisiones durante el desarrollo.
6. Producción siempre encuentra los problemas
Antes del despliegue hicimos pruebas y todo parecía funcionar correctamente.
Pero producción siempre es diferente:
- más usuarios
- más concurrencia
- casos de uso que nadie había probado
Fue precisamente con 5.000–6.000 usuarios concurrentes cuando empezaron a aparecer los problemas de conexiones acumuladas.
Esto es algo que con el tiempo aprendes a aceptar:
por muy buenas que sean las pruebas, producción siempre termina enseñándote algo nuevo.
7. Ser senior no significa saber más frameworks
Cuando empiezas tu carrera es fácil pensar que avanzar como desarrollador significa aprender más tecnologías.
Pero con el tiempo te das cuenta de que muchas de las habilidades más valiosas son otras:
- detectar problemas de arquitectura
- simplificar sistemas
- entender cómo se comporta una aplicación bajo carga
- tomar decisiones que reduzcan la complejidad
Este proyecto fue un buen recordatorio de que la experiencia no consiste en conocer más herramientas, sino en entender mejor cómo funcionan los sistemas reales.
Top comments (0)