Débitos técnicos

O servidor principal tem 92.341 linhas de código organizadas de três formas diferentes ao mesmo tempo, sem fronteira declarada entre elas:

A regra oficial do projeto é clara — funcionalidade nova nasce em src/v3/ no padrão DDD, código legado só recebe correção no lugar. O problema não é a regra: é que nada no código a torna visível. Quem chega não distingue as três zonas, e as ferramentas não impedem que uma invada a outra.

Toda tarefa começa com a mesma pergunta perdida: onde isso deveria morar? E como a resposta depende de quem está fazendo, o mesmo tipo de regra acaba escrito em dois lugares — uma vez no serviço antigo, outra no caso de uso novo. Quando divergem, divergem em silêncio: as duas versões continuam funcionando, dando respostas diferentes.

O custo não aparece numa tarefa específica. Ele aparece como lentidão constante em todas, e como uma classe de bug difícil de rastrear — o comportamento muda conforme o caminho que a requisição tomou.

Em toda funcionalidade nova que toca o servidor principal, e com força maior nas áreas onde 2.0 e 3.0 se encostam: loja, checkout, pedidos e perfil. Também afeta a entrada de qualquer pessoa nova no projeto, que precisa aprender três convenções antes de escrever a primeira linha.

Não é reescrever o servidor. Reescrita grande de sistema em produção costuma custar o dobro do previsto e entregar o mesmo comportamento — com bugs novos. O caminho é tornar a fronteira explícita e deixar o legado encolher sozinho:

1. Escrever a regra como documento curto de decisão (ADR) dentro do repositório, com exemplos dos dois lados.
2. Marcar o legado como zona congelada — um README em cada pasta antiga dizendo o que pode e o que não pode acontecer ali.
3. Ligar uma verificação automática que impeça src/v3/ de importar do legado. É o que transforma a regra em garantia.
4. Absorver src/modules/shipping/ num dos dois lados, eliminando o terceiro padrão.
5. A partir daí, cada funcionalidade nova nasce certa, e o legado só diminui.

Cobre a fronteira inteira: o documento de decisão, a marcação das zonas, a verificação automática e a absorção do módulo solto. Não resolve o legado que já existe — isso é o item 02 —, mas estanca o crescimento da dívida, que é o mais urgente dos dois.

Cinco arquivos concentram as regras mais importantes do negócio — venda, troca, checkout e conta — e cada um cresceu muito além do que se lê de uma vez:

Arquivo desse tamanho não cabe na cabeça de ninguém de uma vez. Na prática isso produz três efeitos, todos caros:

• Mudança arriscada. Alterar uma linha do checkout exige entender 1.226 para ter certeza de que nada mais dependia dela. Como ninguém faz isso toda vez, a certeza vira torcida.
• Teste difícil. Para testar um comportamento pequeno é preciso montar todo o resto do serviço. É por isso que a cobertura fica baixa justamente onde o dinheiro passa.
• Conflito constante. Duas pessoas mexendo em coisas não relacionadas colidem no mesmo arquivo.

Diretamente no coração comercial: venda, troca, pagamento e envio. São exatamente as áreas em que um bug custa dinheiro de verdade — e as que mais recebem alteração, porque são as que o negócio mais mexe.

Quebrar por caso de uso, um de cada vez, e só quando houver motivo para tocar no arquivo. Refatoração em bloco de código que ninguém pediu para mudar é risco sem retorno.

1. Antes de mexer, escrever testes que descrevem o comportamento atual — inclusive o esquisito. Eles são a rede: se algum quebrar depois, a extração mudou o que não devia.
2. Extrair um caso de uso por vez (“comprar etiqueta”, “calcular frete”), com o serviço antigo passando a apenas chamar o novo.
3. Quando o serviço antigo virar só uma lista de chamadas, apagá-lo.

Essa é a parte do trabalho em que a IA mais ajuda: mapear todos os pontos de uso e gerar os testes de caracterização é lento para uma pessoa e rápido com assistência.

O maior item da lista, e também o mais diluível: não precisa virar projeto próprio. Cada vez que uma tarefa encostar num desses arquivos, ela paga a extração daquele pedaço. Assim o custo se dissolve nas entregas e o risco de cada passo fica pequeno.

A dashboard aponta para o mesmo banco que atende o aplicativo, e não faz consultas leves: são relatórios com contagens e agregações escritos à mão.

Relatório e venda disputam a mesma máquina. Quando alguém do time abre um painel pesado, o banco divide memória e disco entre a consulta administrativa e o checkout de um cliente — e o cliente é quem espera.

O sintoma é traiçoeiro porque aparece longe da causa: o aplicativo fica lento em um horário específico e ninguém liga o fato a alguém consultando um relatório.

Na experiência de todo mundo que usa o aplicativo enquanto o time consulta a dashboard. O risco cresce com a base: quanto mais dados, mais cara cada agregação, e hoje não há teto — uma consulta pesada pode segurar o banco sem limite de tempo.

Em escada, do mais barato ao mais caro — e possivelmente parando no segundo degrau:

1. Medir antes de construir. Ligar a medição de consultas do PostgreSQL e descobrir quais realmente doem. Lentidão de painel quase sempre é índice faltando, não falta de servidor.
2. Índices e um teto de tempo. Um limite por consulta no usuário da dashboard impede que qualquer relatório trave a produção. Duas linhas de configuração.
3. Resumos pré-calculados para os números que toleram alguns minutos de atraso — e quase todo número de painel tolera. Tira o peso sem máquina nova.
4. Só então, uma réplica de leitura. Cópia do banco que se atualiza sozinha e recebe as consultas pesadas.

Os dois primeiros degraus são os baratos, e podem encerrar o assunto sozinhos. Vale percorrê-los antes de decidir os últimos: construir réplica sem medir é resolver um problema que talvez não exista.

Um único servidor de 2 núcleos e 8 GB hospeda hoje três serviços — e o plano de virada prevê colocar mais dois na mesma máquina:

A memória até cabe, apertada. O que não cabe é o processamento: o serviço de mídia analisa cada imagem e vídeo com dois modelos de inteligência artificial que rodam na própria máquina. Um único vídeo passa por dez análises em sequência.

Enquanto isso acontece, os dois núcleos ficam ocupados — e quem perde processamento é o servidor principal, no meio de um checkout. O sintoma aparece como lentidão na compra, a quilômetros da causa real.

No aplicativo inteiro, no pior momento possível: no dia da virada, quando o volume muda e todo mundo está olhando. E impede, na prática, ligar a moderação automática de conteúdo — que é uma proteção de marca, não um enfeite.

Separar em duas máquinas, deixando o servidor principal sozinho:

1. Contratar um servidor para mídia, chat e dashboard. Com moderação ligada, 4 núcleos e 16 GB é o mínimo confortável; sem ela, 2 e 8 bastam.
2. Instalar o executor de deploy nesse servidor com uma identificação própria — a mudança nas esteiras é de uma linha em cada.
3. Mover a dashboard primeiro: já existe, é interna e serve de ensaio para validar deploy, certificado e troca de endereço com risco baixo.
4. Depois chat e mídia, que ganham endereço próprio na internet.
5. Virar com a moderação desligada e ligá-la em seguida, medindo.

Boa parte do trabalho já estava prevista no plano de virada, que também precisaria criar endereço, certificado e banco para a mídia — só que no servidor errado. O acréscimo real sobre o que já estava planejado é a mudança da dashboard.

O chat que atende os usuários hoje é um serviço próprio, mas roda debaixo do endereço do servidor principal: um processo separado na porta 8282, ao qual o servidor web encaminha o caminho /socket.io/. De fora parece um sistema só.

O chat reconstruído — com negociação, propostas e troca — está pronto há meses e nunca foi publicado. Todo o valor dele está parado.

Pior que isso: a documentação de virada afirmava que o chat “já tem servidor, endereço e certificado no ar”. É verdade sobre o servidor principal, que hospeda o chat antigo — e falso sobre o serviço novo, que não tem endereço nenhum. Planejamento feito sobre essa frase subestima o trabalho.

Na negociação entre comprador e vendedor, que é o coração do marketplace, e no planejamento da virada, que contava com uma etapa já pronta que não estava.

Há uma vantagem escondida aqui: como o chat antigo atende por outro endereço, os dois podem conviver.

1. Criar o endereço próprio do chat e subir a versão 3.0 no servidor novo, com o legado ainda no ar.
2. Testar à vontade, sem afetar ninguém.
3. Migrar as conversas antigas para o formato novo — o roteiro já existe no repositório.
4. Virar pelo aplicativo, que já aponta para o endereço novo por padrão.
5. Manter o legado enquanto houver versão antiga do app nas mãos dos usuários — quem não atualizar continua com chat funcionando.
6. Corrigir a descrição da topologia na aba de virada.

Subir e apontar é a parte rápida; a migração das conversas antigas é a que pede atenção. E nada disso tem interrupção de serviço, graças à convivência entre os dois chats.