Pular para o conteúdo
/thiago.lu

Migração com paridade provada

Uma aplicação Node.js virou Rails 7 numa fintech de crédito ao consumidor, sem parar a operação. A cada API, a versão nova só assumiu depois de responder igual à antiga em produção.

Ruby on Rails 7 Node.js Contract Testing 2023

O contexto

Um sistema financeiro rodava em Node.js. A empresa decidiu construir uma aplicação Rails mais robusta para controlar as integrações de gestão de contratos dentro dos ERPs do banco. São as mesmas integrações de que dependem a concessão e o acompanhamento do crédito.

A restrição

Não dava para parar. Em crédito ao consumidor, cada requisição que sai errada é dinheiro de um cliente real.

O trabalho estava em garantir paridade de requisição entre o legado e a versão nova, uma integração de cada vez, com o negócio rodando.

A abordagem

Strangler fig com tráfego-sombra. Os dois sistemas rodam em paralelo e cada requisição de produção passa por um switch que decide quem responde. A requisição roda também no outro lado em replay, para comparar as respostas. Confirmada a paridade numa API, o switch vira para o sistema novo. API por API, até não sobrar nada no legado.

Requisição de produção
switch

quem responde de verdade

Legado

Node.js

Novo

Rails 7

replay nos dois → compara a resposta

paridade provada, API por API vira a chave

Por que não de uma vez

Corte único parece mais rápido e é onde eu já vi mais projeto quebrar. A divergência aparece em produção, com dinheiro de cliente no meio, e o rollback custa mais que a migração inteira.

Migrar por módulo é a segunda tentativa de todo mundo. Módulo é fronteira de diagrama. As dependências reais não respeitam.

Eu corto por comportamento. Cada requisição roda nos dois lados e as respostas são comparadas. A chave vira quando param de divergir, e não antes.

Onde isso rendeu menos do que eu esperava: boa parte das divergências que o replay apontou era diferença de formato de dado entre as duas linguagens, não erro de regra de negócio. Para esse tipo, um QA com requisito de produto bem escrito chega antes e custa menos que montar a comparação. O replay se paga quando o risco é a regra, e não a serialização.

O resultado

Cada API passou a ser servida pelo sistema novo depois que o replay mostrou resposta idêntica à do legado. A operação não parou em nenhum momento da transição.

Ver serviços  Voltar para os projetos