Mantenha seu parser vivo quando a API adiciona um campo

Um feed JSON não fica congelado. Campos são adicionados, tipos de mercado se multiplicam, e uma enumeração ganha um membro que você nunca viu. Se o seu parser trata toda surpresa como fatal, seu pipeline cai numa terça-feira tranquila sem mais nada errado. A regra de trabalho é mais antiga que JSON: exija os campos que você usa, tolere todo o resto.

Adições não são quebras

Uma API que adiciona um campo aos seus objetos de evento não quebrou nada. O array de eventos continua lá, o cursor continua lá, e todo campo que você lê ainda significa o que significava. A falha só acontece se o seu código insiste em conhecer cada chave antecipadamente, por exemplo ao desserializar para um tipo de registro rígido que rejeita membros desconhecidos, ou ao afirmar um conjunto fixo de nomes de mercado.

O runbook de tratamento de erros já traça a linha para a outra direção: exija o envelope documentado, o array de eventos e o cursor, antes de tocar no payload. Essa exigência é sobre o que deve estar presente. A compatibilidade futura é sobre o que também pode estar presente.

Duas regras para um parser tolerante

Primeiro, leia por nome, nunca por posição ou por listagem exaustiva. Busque os campos que a sua lógica precisa e ignore o resto; um parser que itera sobre todas as chaves e faz switch em cada uma vai encontrar uma chave para a qual não tem caso.

Segundo, valide valores, não vocabulários. Confira que o preço é um número acima de um, que o timestamp faz parse, que o id do evento está presente. Não confira se o nome do mercado pertence a uma lista que você escreveu em março, porque a lista é a parte que envelhece. O aviso do runbook sobre nulos também vale aqui: um preço null significa que o mercado está fechado ou indisponível, e a resposta correta é mantê-lo null, nunca substituir por zero.

Registre a deriva sem falhar por ela

Tolerância não significa cegueira. Quando seu parser encontra um campo ou valor que não conhece, conte e siga em frente. Uma linha em nível debug ou um contador por chave desconhecida basta. Uma vez por semana, leia as contagens: elas contam o que o feed adicionou, o que muitas vezes é um recurso que você agora pode usar, como um novo tipo de mercado que pode começar a armazenar.

Esta é a diferença entre derivar e quebrar. Derivar é o feed crescendo ao seu redor; quebrar é o seu código se recusando a crescer com ele.

Fixe o contrato com fixtures

Um punhado de respostas gravadas na sua suíte de testes transforma a política em checagem: o parser deve aceitar os envelopes gravados, extrair o que você usa, e dar de ombros para um evento sintético carregando campos extras inventados. Quando o feed documentar uma mudança genuinamente quebradora, isso é uma migração a planejar, não uma surpresa a sobreviver. Até lá, a tolerância é o plano.

Exija o envelope, leia por nome, registre o desconhecido. Um parser construído assim só quebra quando o mundo realmente muda, não toda vez que o feed aprende uma palavra nova.