A pressa de culpar o ActiveRecord antes de abrir o plano de execução no PostgreSQL
Antes de espalhar includes pelo código ou criar índices redundantes, entender o EXPLAIN ANALYZE mostra onde o banco realmente perde tempo.
Compartilhando lições aprendidas em produção escalando o Integrar Plus, construindo ferramentas open source para Rails e estruturando sistemas resilientes.
Testes verdes que escondem falhas reais nascem de fixtures permissivas e asserções cegas ao ciclo de vida do ActiveRecord.
Pedro Dalben
CTO no Integrar Plus & Arquiteto Full Stack
Antes de espalhar includes pelo código ou criar índices redundantes, entender o EXPLAIN ANALYZE mostra onde o banco realmente perde tempo.
Trocar o Redis pelo Solid Queue no PostgreSQL simplifica a infraestrutura, mas exige ajustes no banco para evitar degradação por bloat.
Culpar o ORM pelo tempo de resposta costuma esconder falta de leitura do plano de execução do PostgreSQL e índices mal desenhados.
Dividir um monólito Rails em engines ou serviços cria burocracia desnecessária; namespaces puros e contratos explícitos resolvem quase tudo.
Dividir código em pastas ou engines não cria limites de contexto se o banco de dados continuar amarrando seus domínios no mesmo nó.
Como o Solid Queue substitui o Redis utilizando recursos nativos do PostgreSQL para simplificar a infraestrutura de jobs assíncronos no Rails.