Um dos três contratos PJ rodando em paralelo no período (com Bullla e WEX). Dashboard de stakeholders lento travava o negócio reescrevi o backend do zero.
Contexto
Dashboard de stakeholders puxando dados da Facebook API pra analytics acionáveis. Um dos três contratos PJ rodando em paralelo no período (com Bullla e WEX), então a engenharia tinha que ser enxuta e auto-explicativa.
Problema
Dashboard respondendo em 3s no pico. Backend era colcha queries N+1 em todo lugar, cache inexistente, sem observabilidade. Stakeholders evitavam a ferramenta porque era mais rápido perguntar no Slack.
Reescrita
Backend do zero com Next.js no front. Queries otimizadas, cache estratégico (por stakeholder + por janela de tempo), camada de API enxuta que o dashboard podia confiar como fonte única de verdade.
Resultado
Latência caiu de 3s pra 200ms no pico 15× mais rápido. O dashboard virou de 'evitado' pra 'primeiro lugar que stakeholders abrem' pra decisões time-sensitive.
- Por que reescrita de backend em vez de fix incremental?Reescrita completaA colcha tinha mais complexidade acidental que o domínio. Reescrever foi mais rápido que desemaranhar os N+1, a camada de cache ausente e a falta de observabilidade um PR por vez.
- Por que Next.js no front?Next.js + SSRStakeholders abrem o dashboard pelo email/Slack tempo de primeiro byte importa mais que interatividade rica. SSR entregou os dados no primeiro paint, não depois do bundle parsear.
3s → 200ms. Dashboard virou ferramenta de decisão em tempo real pros stakeholders.