Harness publicou um post-mortem sobre refatorar a tabela SQL no núcleo de seu Test Intelligence Service—o backend para seleção de testes, detecção de instabilidade e rastreamento de tendências em pipelines CI. O engenheiro Moshe Tsur documentou o que quebrou em escala, a correção da equipe e os princípios de engenharia que trancaram antes do rollout em produção.

O esquema original era simples e desnormalizado: uma linha por resultado de teste, com identificadores de conta, projeto, pipeline e build armazenados como strings de texto simples em cada linha. Funcionava com milhares de linhas. Com milhões, falhou de três formas.

Primeiro, 93% do armazenamento de linhas era strings de escopo duplicadas. Um pipeline executando 10.000 testes produzia 10.000 cópias idênticas de identificadores de conta e projeto. Segundo, essas colunas de string não podiam ser indexadas como chaves estrangeiras inteiras na hora, então cada filtro fazia comparações de string completas em milhões de linhas—aproximadamente 10x mais lento que buscas inteiras. Terceiro, o caminho de escrita era O(N) dentro da requisição HTTP: 50.000 resultados de teste significavam 50.000 instruções INSERT antes da API retornar. Sob carga concorrente, os serviços ficavam sem memória e expiravam.

A correção foi estrutural. Harness dividiu a tabela em relações normalizadas, substituindo identificadores de string repetidos por referências inteiras. O escopo hierárquico se tornou chaves estrangeiras. Blobs de saída de teste—stdout e stderr—foram separados de metadados leves, para que consultas resumidas parassem de carregar colunas desnecessárias. Agregados pré-computados substituíram varreduras de tabela completa para contagens de sucesso/falha no nível de build.

Três princípios governaram a reescrita. A API deve fazer um número fixo de operações independentemente do tamanho da payload: armazenar entrada, retornar imediatamente, processar assincroniamente. Todo trabalho proporcional ao tamanho dos dados é executado em pools de workers em background via fila. Cada componente obtém um limite de memória explícito; processar em chunks de tamanho fixo e liberar entre iterações.

Harness stress-testou antes do rollout em cenários de surto que o esquema original nunca enfrentou: 1.000 pipelines completando simultaneamente, relatórios únicos com 100.000 resultados de teste. Essa disciplina—quebrar coisas em labs de teste, não em produção—é como identificaram os limites originais.

Esquemas desnormalizados otimizados para simplicidade de escrita acumulam custos de leitura ocultos. A duplicação de 93% e a lentidão de query de 10x são números reais que Harness atingiu em escala de produção, não curvas teóricas. A penalidade string-versus-inteiro é fácil de descartar em tabelas pequenas; com milhões de linhas é o termo dominante em latência. Um caminho de inserção O(N) permanece invisível até que um relatório grande acione OOM. Decisões de esquema tomadas cedo tendem a sobreviver muito além do ponto em que permanecem neutras.

Se a latência do seu write handler escala com o tamanho da payload, você trancou um limite.