Aproveite ao máximo o sistema que você já tem

• O texto discute a experiência do autor ao gerenciar o desempenho do Postgres em uma aplicação SaaS, na qual o banco de dados estava tendo dificuldade para suportar a carga.
• A equipe do autor fazia escalonamento vertical, trocando o banco por uma instância maior sempre que ele ficava ocupado demais. Porém, eles já estavam usando a maior instância disponível e se aproximavam de um estado de sobrecarga.
• Foram propostas duas soluções possíveis: fazer sharding de escritas em clusters de banco de dados independentes e dividir o monólito em vários serviços conectados (microsserviços).
• Ambas as soluções aumentariam a capacidade e ofereceriam opções interessantes de tolerância a falhas e resiliência operacional, mas também elevariam bastante a complexidade.
• O autor argumenta que o custo real do aumento de complexidade é a atenção, o que torna mais complicada toda decisão técnica posterior.
• O autor sugere que, antes de aumentar muito a complexidade, geralmente há espaço para “espremer” um pouco mais de desempenho do sistema existente, seja ajustando a carga de trabalho, otimizando a performance ou complementando o sistema de alguma forma.
• No caso deles, ao otimizar consultas pesadas, ajustar as configurações do Postgres e descarregar algumas consultas caras somente de leitura para um banco de réplicas, eles reduziram o pico semanal de uso de CPU do banco de dados de 90% para 30%.
• O autor conclui que a complexidade é necessária e inevitável, mas que o ideal é adiar esse aumento pelo maior tempo possível e primeiro extrair o máximo de desempenho do sistema existente.

[GN⁺]

Comentários do Hacker News

• O artigo enfatiza a importância de extrair o máximo potencial do sistema atual antes de considerar substituição ou upgrade.
• Sugere que as equipes devem aproveitar o que já têm, mesmo que não seja perfeito, e encontrar maneiras de alcançar seus objetivos com os recursos existentes.
• Discute a ideia de projetar a aplicação para evitar o uso de joins no banco de dados, sugerindo que armazenamento é barato e que tudo deve ser desnormalizado e atualizado em transações.
• Sugere o uso de UUIDs para evitar hot partitions, permitindo escalar horizontalmente em vez de depender de inteiros que podem acabar falhando.
• Compartilha um caso de sucesso em que uma equipe melhorou significativamente o desempenho do sistema ao mudar a forma de resolver o problema, em vez de adicionar mais hardware ou complexidade.
• O artigo desaconselha dividir de uma vez um monólito em vários serviços conectados, e em vez disso sugere identificar a divisão que terá maior impacto.
• Enfatiza a importância de otimizar consultas em aplicações web construídas sobre ORM, onde frequentemente há muito espaço para melhorias.
• Alerta para a carga mental e a complexidade de trabalhar com sistemas de microsserviços, sugerindo que eles muitas vezes causam downtime e confusão.
• Distingue eficiência (minimizar perdas e evitar complexidade) de otimização (usar algoritmos especializados ao custo de adicionar complexidade).
• Compartilha preocupações sobre migrações para infraestruturas mais complexas, sugerindo que isso pode não ser a solução milagrosa que todos esperam.
• Defende a simplicidade em vez da complexidade, especialmente quando os recursos são limitados e o sistema não é extremamente crítico.
• Por fim, o artigo discute sharding por tenant (cliente) como uma solução potencial para problemas de escalabilidade.