SoundCloud comparou em modo shadow um novo protocolo RPC com a produção antes mesmo de servi-lo

O backend da SoundCloud rodava em microsserviços com interfaces REST/JSON construídas manualmente, fáceis de depurar, mas deixando as convenções de cada endpoint a cargo da equipe que o construiu — método HTTP, nomes de campos JSON, formatos de timestamp, formatos de erro. As diretrizes internas ajudavam apenas até certo ponto: um cliente certa vez enviou campos em camelCase para um servidor que esperava snake_case e causou uma indisponibilidade, e entender qualquer endpoint significava ler o código da aplicação em vez de um contrato.

A SoundCloud criou o Twinagle, uma implementação em Scala/Finagle do protocolo RPC Twirp do Twitch, para que os engenheiros pudessem definir uma API uma vez em protobuf e gerar o código de servidor e de cliente a partir dela. Eles migraram primeiro seu serviço de autorização de faixas de alto tráfego. Em vez de fazer a migração diretamente, executaram REST e Twirp lado a lado atrás de uma flag baseada em porcentagem: em baixas porcentagens de implantação, ambos os endpoints eram chamados e comparados, com apenas a resposta REST sendo retornada, de modo que divergências surgiam como discrepâncias registradas em log, não como bugs visíveis ao usuário.

Espelhar o tráfego para o novo endpoint, compará-lo e então fazer a migração

Gerar o código de servidor e de cliente a partir de um único contrato protobuf eliminou a classe de bugs causada por equipes inventando suas próprias convenções de nomenclatura de campos JSON e de HTTP.

Executar ambos os endpoints em paralelo com uma pequena porcentagem de tráfego antes da migração permitiu à equipe detectar divergências de resposta sem que nenhum usuário visse uma resposta errada.

Começar com um serviço de alto tráfego e de cliente único manteve pequena a superfície de integração da primeira migração, ao mesmo tempo em que provava o Twinagle sob carga real.

Manter a lógica de negócios existente intacta e confinar o novo código a uma fina camada de serialização limitou onde novos bugs poderiam se esconder.

Antes de aposentar um sistema em funcionamento, faça o substituto responder a cada requisição em paralelo e compare-o com o sistema vigente — os bugs surgem enquanto o sistema antigo ainda serve a resposta.

A implantação com comparação em modo shadow detectou vários bugs críticos antes que chegassem aos usuários, e a SoundCloud elevou o serviço de autorização de faixas a 100% de tráfego Twirp sem indisponibilidades e sem bugs na primeira tentativa. A largura de banda entre os dois serviços caiu mais de 40% com a troca de JSON por protobuf binário, e a equipe excluiu todo o seu código de serialização JSON personalizado para o serviço. A SoundCloud passou a converter seus outros serviços para o Twinagle e o tornou o padrão para todos os novos serviços daí em diante.