Três projetos, do começo ao fim

O desafio

Plataformas de operadora são camadas sobre camadas. Provisionamento, faturamento, inventário e atendimento guardam pedaços diferentes da verdade, e foram construídos em décadas diferentes por times diferentes. Qualquer mudança precisa respeitar interfaces das quais milhares de outras coisas já dependem.

O que fizemos

• Documentamos o contrato real de cada interface antes de mexer, incluindo o comportamento não documentado
• Construímos as integrações contra schemas explícitos, com validação na fronteira
• Adicionamos IDs de correlação para rastrear a ação de um cliente em cada salto
• Instrumentamos os fluxos com métricas e alertas ligados ao impacto no cliente, não à saúde do servidor

O resultado

• Falhas passaram a aparecer em minutos, em vez de serem descobertas por chamados de suporte
• Reprocessar virou operação de rotina, e não incidente
• Novas interfaces puderam ser adicionadas sem renegociar a cadeia inteira

O desafio

Dado de varejo só serve se estiver atual. Preço muda, estoque anda, pedido chega mais rápido do que uma carga noturna consegue processar, e cada sistema envolvido tinha a sua própria ideia do que é um código de produto.

O que fizemos

• Trocamos cargas noturnas por sincronização incremental onde a latência realmente importava
• Construímos uma camada de mapeamento para cada sistema manter os seus códigos sem quebrar os outros
• Adicionamos rotinas de conciliação que comparam os dois lados e relatam diferenças em vez de escondê-las
• Colocamos o fluxo inteiro em um painel que a operação lê todo dia

O resultado

• Diferenças de estoque e preço são pegas no mesmo dia, não no fechamento do mês
• O fluxo de pedidos continua andando quando um sistema fica indisponível, e depois se recupera
• A operação enxerga o estado de cada fluxo sem precisar perguntar para um desenvolvedor

O desafio

O negócio não podia parar e os autores originais já não estavam mais lá. A reescrita foi proposta duas vezes e abandonada duas vezes, porque o risco era impossível de justificar.

O que fizemos

• Envolvemos o sistema legado em uma fachada de API para que o código novo nunca falasse direto com ele
• Adicionamos testes de caracterização em volta do comportamento que importava antes de mudar qualquer coisa
• Movemos uma capacidade por vez para trás da fachada, com escrita dupla durante cada transição
• Mantivemos os dois sistemas conciliados continuamente até o caminho antigo poder ser desligado

O resultado

• A migração aconteceu sem congelar o negócio e sem janela de parada anunciada
• Cada fatia podia voltar atrás sozinha, então o risco ficou pequeno
• O time deixou de ter medo de fazer deploy naquela parte do sistema