"Performance em cima de dado errado é só mentira rápida" resume bem. Responder em 10ms uma consulta sobre um CNPJ que não existe mais, ou com sócio desatualizado, é pior do que não responder. O dado da Receita é a matéria-prima do produto inteiro; se a carga mensal degrada silenciosamente, todo o resto vira fachada.

Hoje o pipeline já rejeita linha inválida e loga contagem por arquivo, mas a sua lista é basicamente meu backlog de hardening: checksum dos arquivos baixados, detecção de mudança de layout (a Receita já mudou formato sem avisar antes, então isso é questão de quando, não se), e principalmente carga em staging com validação de sanidade antes do swap — comparar contagem de linhas e distribuição com a base anterior, e abortar se o desvio for anômalo. Swap atômico de schema no Postgres torna isso barato de fazer, então não tem desculpa.

Sobre denormalização e Redis: concordo, e foi por isso que ainda não fiz nenhum dos dois. O EXPLAIN ANALYZE com índice certo mostrou que o join nem aparece no perfil da consulta. Cada peça nova precisa pagar aluguel — e por enquanto Postgres bem indexado está pagando o de todo mundo.