Exprime al máximo el sistema que ya tienes

• El artículo analiza la experiencia del autor gestionando el rendimiento de Postgres en una aplicación SaaS, donde la base de datos tenía dificultades para soportar la carga.
• El equipo del autor escaló verticalmente reemplazando la base de datos por una instancia más grande cada vez que estaba demasiado ocupada. Sin embargo, ya estaban usando la instancia más grande y estaban a punto de entrar en una situación de sobrecarga.
• Se propusieron dos posibles soluciones: hacer sharding de las escrituras en clústeres de bases de datos independientes y dividir el monolito en varios servicios conectados entre sí (microservicios).
• Ambas soluciones aumentarían la capacidad y ofrecerían opciones interesantes de tolerancia a fallas y resiliencia operativa, pero también incrementarían mucho la complejidad.
• El autor sostiene que el costo real de aumentar la complejidad es la atención, y que eso complica todas las decisiones técnicas posteriores.
• El autor sugiere que, antes de aumentar mucho la complejidad, por lo general existe la oportunidad de “exprimir” un poco más de rendimiento del sistema actual ajustando la carga de trabajo, afinando el rendimiento o complementando el sistema de alguna manera.
• En su caso, al optimizar consultas pesadas, ajustar la configuración de Postgres y descargar algunas consultas costosas de solo lectura a una base de datos réplica, redujeron el uso máximo semanal de CPU de la base de datos de 90% a 30%.
• El autor concluye que la complejidad es necesaria e inevitable, pero que es preferible posponer su aumento durante el mayor tiempo posible y primero exprimir al máximo el rendimiento del sistema existente.

[GN⁺]

Opiniones de Hacker News

• El artículo enfatiza la importancia de aprovechar al máximo el potencial del sistema actual antes de considerar reemplazos o actualizaciones.
• Sugiere que los equipos deben usar lo que ya tienen, aunque no sea perfecto, y encontrar formas de alcanzar sus objetivos con los recursos existentes.
• Analiza la idea de diseñar la aplicación para evitar usar joins en la base de datos, y propone que el almacenamiento es barato y que todo debería estar desnormalizado y actualizarse dentro de transacciones.
• Se propone usar UUID para evitar particiones calientes, lo que permite escalar horizontalmente en lugar de depender de enteros que eventualmente pueden fallar.
• Comparte un caso de éxito en el que un equipo mejoró enormemente el rendimiento del sistema al cambiar su enfoque para resolver el problema, en lugar de agregar más hardware o complejidad.
• El artículo desaconseja dividir un monolito de una sola vez en varios servicios conectados, y en su lugar propone identificar la división que tendría el mayor impacto.
• Destaca la importancia de optimizar consultas en aplicaciones web construidas sobre un ORM, donde a menudo hay mucho margen de mejora.
• Advierte sobre la carga mental y la complejidad de trabajar con sistemas de microservicios, sugiriendo que a menudo provocan tiempo de inactividad y confusión.
• Distingue entre eficiencia (minimizar pérdidas y evitar complejidad) y optimización (usar algoritmos especializados a costa de agregar complejidad).
• Comparte preocupaciones sobre migrar hacia una infraestructura más compleja, sugiriendo que quizá no sea la solución mágica que todos esperan.
• Se inclina por la simplicidad por encima de la complejidad, especialmente cuando los recursos son limitados y el sistema no es de misión crítica.
• Por último, el artículo menciona el sharding por tenant (cliente) como una posible solución a los problemas de escalabilidad.