Case · Aviação · Cliente anônimo
De eventos XML profundamente aninhados a nove entidades de negócio prontas para análise, com reprocessamento seguro, reconciliação exata e idempotência em cada fronteira.
O contexto
Uma companhia aérea recebia continuamente os eventos do ciclo de vida dos seus bilhetes por meio de um GDS. Emissões, trocas, reembolsos, anulações, taxas e formas de pagamento chegavam por uma fila de mensagens, dentro de uma estrutura XML profundamente aninhada.
A consolidação dependia de uma implementação artesanal de Spark Streaming. Escritas manuais, triggers fixos e regras distribuídas por notebooks tornavam a operação difícil de testar e reprocessar. A análise comercial recebia a informação consolidada com latência de dias.
Nosso mandato cobriu a substituição de ponta a ponta, da integração com a fila ao modelo de negócio. Antes de desenhar a arquitetura, questionamos onde a baixa latência realmente mudaria uma decisão. Essa pergunta evitou espalhar complexidade de streaming por camadas que não precisavam dela.
Tempo real só se paga quando existe, do outro lado, uma decisão que não pode esperar pelo processamento da noite.
O desafio
A solução precisava operar continuamente, suportar XML complexo, conviver com entrega at-least-once e manter a consistência de um modelo usado em análise financeira. Tudo isso sem transformar cada falha em uma intervenção manual nem criar uma arquitetura impossível de promover entre ambientes.
Nossa abordagem
Desenhamos uma fronteira serverless para consumir e preservar as mensagens, um pipeline contínuo para ingestão e normalização e outro para materializar o modelo de negócio. Cada camada recebeu a semântica adequada ao problema que resolve, com configuração versionada e lógica testável.
Arquitetura publicável
A mensagem só sai da fila depois que o payload original está preservado. A partir daí, dois pipelines declarativos transformam o XML em dados normalizados e entidades de negócio.
Decisões-chave
Aterrar cada mensagem como arquivo parecia um salto extra. Na prática, criou um registro imutável, desacoplou o pipeline da retenção da fila e permitiu rastrear qualquer linha até o payload de origem.
Resultado: reprocessamentos manuais deixaram de existir.
O ledger protege contra a reentrega da mesma mensagem após uma falha. No lakehouse, uma ordenação explícita por chave de negócio escolhe de forma determinística a versão correta de cada fato.
Resultado: correções manuais de duplicados deixaram de existir.
Quando faltava uma referência para distribuir um valor entre segmentos, o método alternativo era aplicado ao documento inteiro. Assim, a soma dos segmentos continuava igual ao total do documento.
Resultado: reconciliações manuais deixaram de existir.
Ingestão e normalização operam continuamente. O modelo de negócio usa materializações incrementais, evitando joins e agregações frágeis entre múltiplos streams em troca de uma redução marginal de latência.
Resultado: baixa latência com uma operação compreensível e testável.
Em produção
O artigo técnico explica onde paramos o streaming, como tratamos reentregas e cinco falhas que mudaram nosso modo de construir pipelines.