Cases de sucesso
Dados em tempo real para um dos maiores grupos seguradores do mundo
Modernizámos a arquitetura financeira, contabilística e analítica da operação brasileira, com integrações em tempo real via Apache Kafka e Confluent e uma plataforma de alta segurança para o processamento internacional de dados.
Saiba maisCases de sucesso
Um Centro de Excelência para a maior rede de saúde da América Latina
Consolidámos operação, sustentação e projetos numa única estrutura de integração. Os eventos hospitalares passaram a ser processados em cerca de 20 segundos, com automatização completa do processo de glosas.
Saiba maisCases de sucesso
Stock fluido e operação unificada num dos maiores retalhistas do Brasil
Suportámos a transformação digital com uma arquitetura moderna em React, React Native, Java e RabbitMQ, criando o conceito de Stock Fluido e a gestão unificada de stocks, encomendas e expedições.
Saiba maisEstamos prontos para ajudá-lo com eficiência.
Do legado batch a uma arquitetura resiliente e orientada a eventos.
Uma grande companhia do setor financeiro precisava transformar profundamente sua arquitetura de integrações no Brasil.
Durante anos, processos críticos de contabilidade, pagamentos, lançamentos financeiros e dados regulamentares dependiam de integrações legadas predominantemente baseadas em ficheiros e processamento batch.
O desafio ia muito além de substituir interfaces.
Era necessário migrar o ecossistema financeiro brasileiro para o padrão corporativo global, centralizando as integrações numa plataforma financeira utilizada pela organização nos Estados Unidos, sem perder a compatibilidade com sistemas locais que continuariam em operação.
Isto significava modernizar dezenas de fluxos envolvendo sistemas de seguros, pagamentos, recursos humanos, contabilidade e obrigações regulamentares, preservando a operação dos sistemas legados durante a transição.
Nem todas as integrações deveriam tornar-se em tempo real.
Um dos principais desafios de arquitetura foi identificar quais processos continuariam mais eficientes em batch de elevado volume e quais deveriam evoluir para um modelo assíncrono e orientado a eventos.
A nova arquitetura passou a suportar os dois modelos.
Para integrações transacionais e eventos que precisavam circular rapidamente entre sistemas, foram desenvolvidos serviços assíncronos em Java e Spring Boot, utilizando APIs e mecanismos de mensageria.
Para cargas financeiras volumosas, o processamento batch foi preservado, porém modernizado com mecanismos adicionais de controlo, segurança, rastreabilidade e recuperação.
A comunicação entre plataformas passou a utilizar diferentes estratégias conforme a natureza da integração:
O objetivo não era simplesmente transportar informações, mas construir uma camada de integração capaz de absorver diferenças entre sistemas locais e a plataforma financeira global.
Algumas integrações financeiras movimentavam ficheiros de grande volume.
Nesses cenários, simplesmente transportar o ficheiro original pela infraestrutura não era suficiente.
Foi implementado um mecanismo específico de compactação e descompactação dos lotes, reduzindo o volume transmitido e aumentando a eficiência do processamento.
O pipeline também precisava tratar informações financeiras e pessoais com requisitos elevados de segurança.
Por isso, a solução incorporou mecanismos para encriptar colunas sensíveis, protegendo determinados campos individualmente; identificar e remover informações confidenciais dos eventos antes da respetiva publicação no Kafka, evitando que dados desnecessários ou sensíveis circulassem pela plataforma de mensageria; e manter somente as informações necessárias para o processamento de cada integração.
Essa abordagem permitiu combinar elevado throughput com privacy by design, evitando transformar a plataforma de eventos em um repositório indiscriminado de informações confidenciais.
Outro desafio importante era evitar que a modernização financeira obrigasse todos os sistemas existentes a serem alterados simultaneamente.
Para isso foram construídos adapters.
Sistemas legados podiam continuar produzindo determinados ficheiros em seu formato original, enquanto a nova camada de integração convertia essas informações para os novos serviços.
O mesmo conceito foi aplicado ao fluxo de retorno.
A plataforma moderna processava a transação e o adapter podia transformar a resposta novamente no formato compreendido pelo sistema legado.
Essa estratégia reduziu drasticamente o acoplamento da transformação e permitiu uma migração progressiva.
Numa arquitetura financeira, perder uma mensagem ou processar parcialmente um lote pode gerar impactos muito maiores do que uma simples indisponibilidade técnica.
Por isso, a solução foi desenhada com forte preocupação com resiliência, rastreabilidade e consistência.
Os fluxos incluíam:
Nos processos contabilísticos, determinados lotes seguiam uma lógica de integridade do tipo all-or-nothing: um conjunto de registos deveria ser aceite integralmente ou rejeitado como um único batch, evitando contabilizações parciais.
O resultado foi uma arquitetura capaz de lidar simultaneamente com integrações em tempo real e grandes cargas batch sem abandonar os controlos exigidos por sistemas financeiros.
A transformação teve ainda um componente adicional de complexidade: não se tratava apenas de modernizar tecnologia.
As integrações contábeis e financeiras brasileiras precisavam ser adaptadas ao modelo financeiro corporativo utilizado pela mpresa-mãe nos Estados Unidos.
Foram mapeados sistemas, layouts, campos, regras de negócio, eventos contabilísticos, pagamentos e retornos existentes no Brasil para que pudessem operar com a nova instância corporativa do Oracle EBS.
Entre os domínios envolvidos estavam:
• Pagamentos e retornos bancários
• General Ledger (GL)
• Lançamentos contabilísticos
• Sistemas de emissão de apólices
• Comissões e compensações
• Franquias
• Dados de funcionários
• Informações regulamentares
• Movimentos financeiros
Mais do que uma migração de interfaces, o projeto representou a criação de uma camada moderna de interoperabilidade entre o ecossistema financeiro brasileiro e uma plataforma financeira global.
Projetos de modernização de integrações não precisam de escolher entre batch ou tempo real. A arquitetura correta utiliza cada modelo onde faz mais sentido.
Neste projeto, serviços modernos, eventos, APIs e Kafka passaram a coexistir com processamento batch de elevado volume, sistemas legados e plataformas financeiras corporativas.
O resultado foi uma arquitetura mais desacoplada, resiliente, segura e preparada para evoluir sem exigir a substituição simultânea de todo o ecossistema existente.
Uma grande operação de saúde precisava de transformar os dados gerados nos hospitais em informação acionável em segundos.
Com nova modelação de dados, arquitetura de streaming e otimizações de processamento, a latência passou de cerca de 20 minutos para aproximadamente 20 segundos, num modelo que hoje suporta mais de 100 hospitais.
Os dados eram provenientes de diferentes sistemas hospitalares, incluindo TASY, WPD e MV, com estruturas e modelos distintos.
O desafio não consistia apenas em acelerar o processamento: era necessário reorganizar profundamente a forma como os dados eram modelados, tratados e disponibilizados.
O ganho de desempenho começou pela arquitetura de dados. Antes de optimizar a infraestrutura, foi revista a organização da informação, com uma definição adequada de factos, dimensões, particionamento, relações, tabelas de correspondência e estratégias de processamento incremental.
Esta remodelação eliminou etapas desnecessárias, reduziu a movimentação de dados e permitiu que Spark, Delta e Delta Live Tables funcionassem de forma muito mais eficiente.
O resultado não surgiu apenas de tuning técnico, mas da combinação entre engenharia de dados, modelação analítica e desenho correto dos pipelines.
O CDC inicialmente utilizado na captura dos sistemas transaccionais evoluiu para uma implementação baseada em Debezium personalizado, adaptada às necessidades específicas do ambiente hospitalar, permitindo um maior controlo sobre a captura, transformação e publicação dos eventos.
O CDC inicialmente utilizado na captura dos sistemas transaccionais evoluiu para uma implementação baseada em Debezium personalizado, adaptada às necessidades específicas do ambiente hospitalar, permitindo um maior controlo sobre a captura, transformação e publicação dos eventos.
Java com Quarkus e Node.js foram utilizados na construção dos serviços responsáveis pelas integraçõese regras de negócio.
Rabbit MQ suportava diferentes fluxos de processamento assíncrono, enquanto o ecossistema Kafka disponibilizado através do Azure Event Hubs permitia distribuir eventos entre os diferentes componentes da plataforma.
React e React Native eram utilizados nas aplicações web e nas aplicações que apoiavam a operação das lojas.
O resultado foi uma arquitetura distribuída capaz de processar movimentos provenientes deaproximadamente 1.800 lojas e de manter diferentes sistemas atualizados, sem criar dependênciassíncronas entre todos os elementos da cadeia.
Com a combinação de nova modelação, arquitetura de streaming e otimizações de processamento, a latência, anteriormente na ordem dos 20 minutos, foi reduzida para aproximadamente 20 segundos.
Isto permitiu transformar dados hospitalares em eventos de negócio utilizáveis praticamente no momento em que o atendimento ocorria.
Entre os casos de uso estavam:
O modelo criado inicialmente para um conjunto controlado de hospitais evoluiu e suporta hoje um cenário com mais de 100 hospitais.
Mais do que implementar uma plataforma de dados, o projecto demonstrou uma capacidade essencial da Best2bee:
identificar onde está realmente o problema de desempenho — arquitetura, modelo, processamento ou infraestrutura — e redesenhar o conjunto para que Analytics possa operar em escala e em tempo quase real.
Uma das maiores operações de retalho do Brasil precisava de enfrentar um desafio essencial para a evolução da sua estratégia omnicanal: garantir que o stock das lojas físicas, dos canais digitais e do ERP corporativo representasse, de forma consistente e com baixa latência, a disponibilidade real dos produtos.
Com aproximadamente 1.800 lojas físicas, qualquer atraso na propagação dos movimentos de stock gerava divergências relevantes entre os diferentes canais.
Um produto vendido fisicamente podia continuar disponível no e-commerce durante algum tempo. Da mesma forma, novas mercadorias recebidas pelas lojas nem sempre ficavam imediatamente disponíveis para os restantes canais.
O desafio não consistia apenas em integrar sistemas.
Era necessário criar uma arquitetura capaz de transformar milhares de lojas físicas numa parte ativa da operação digital.
A iniciativa de Stock Fluido teve como objetivo aproximar os stocks físico e digital, permitindo que os movimentos realizados nas lojas fossem propagados rapidamente para os restantes componentes do ecossistema.
O SAP, utilizado como ERP corporativo, desempenhava um papel central neste processo, enquanto as aplicações e os serviços responsáveis pela operação das lojas precisavam de manter a informação de stock sincronizada com os canais digitais.
A arquitetura passou a trabalhar com eventos de movimentação de stock, reduzindo significativamente o tempo necessário para que as alterações realizadas nas aproximadamente 1.800 lojas fossem refletidas nos restantes sistemas.
Isto permitiu reduzir a diferença entre o stock existente fisicamente e aquele apresentado ao consumidor nos canais online.
Disponibilizar o stock das lojas para o e-commerce não significava expor toda a quantidade existente.
A solução incorporava o conceito de stock mínimo de segurança.
Parte do stock permanecia reservada para responder às necessidades da operação local da loja,enquanto apenas a quantidade considerada disponível podia ser oferecida aos canais digitais.
Esta abordagem permitia utilizar as lojas como pontos de stock da operação omnicanal sem comprometer a experiência dos clientes que realizavam as suas compras presencialmente.
Com uma visão mais atualizada da disponibilidade dos produtos, as lojas passaram a desempenhar um papel ainda mais importante na jornada digital.
A arquitetura suportava diferentes modelos de O2O — Online to Offline — incluindo:
• compra realizada online com levantamento do produto em loja;
• compra realizada online com preparação e entrega a partir da própria loja.
Neste modelo, uma loja física deixa de ser apenas um ponto de venda e passa também a fazer parte da rede logística da operação digital.
Para que isto fosse possível, stock, encomenda, preparação e disponibilidade precisavam de funcionar de forma coordenada.
O projeto abrangia também o processo de abastecimento das lojas.
Quando os produtos eram expedidos a partir dos Centros de Distribuição, as aplicações utilizadas pela operação permitiam controlar a receção das mercadorias nas lojas.
A confirmação da receção atualizava o stock da loja e propagava essa informação para o restante ecossistema, incluindo o ERP corporativo e os serviços responsáveis pela disponibilidade dos produtos.
O fluxo aproximava diferentes etapas da cadeia:
Centro de Distribuição → receção em loja → confirmação da mercadoria → atualização do stock →
SAP → canais digitais
Desta forma, a arquitetura acompanhava o produto desde a sua chegada à loja até à respetiva disponibilização para venda nos diferentes canais.
Para reduzir o acoplamento entre sistemas e permitir que os movimentos de stock fossem processados de forma assíncrona, foi adotada uma arquitetura fortemente baseada em eventos e mensageria.
Entre as principais tecnologias utilizadas estavam:
Java • Quarkus • Node.js • React • React Native • RabbitMQ • Azure Event Hubs / Kafka • SAP •
arquitetura orientada a eventos • microsserviços
Java com Quarkus e Node.js foram utilizados na construção dos serviços responsáveis pelas integraçõese regras de negócio.
RabbitMQ suportava diferentes fluxos de processamento assíncrono, enquanto o ecossistema Kafka disponibilizado através do Azure Event Hubs permitia distribuir eventos entre os diferentes componentes da plataforma.
React e React Native eram utilizados nas aplicações web e nas aplicações que apoiavam a operação das lojas.
O resultado foi uma arquitetura distribuída capaz de processar movimentos provenientes de aproximadamente 1.800 lojas e de manter diferentes sistemas atualizados, sem criar dependências síncronas entre todos os elementos da cadeia.
A evolução do Stock Fluido fazia parte de uma transformação mais ampla da operação das lojas.
Para além dos serviços relacionados com a sincronização e disponibilidade de stock, foram desenvolvidas soluções para diferentes processos do retalho, incluindo:
• receção de mercadorias provenientes dos Centros de Distribuição;
• levantamento em loja de encomendas realizadas nos canais online;
• entrega de encomendas digitais utilizando a própria loja como ponto de origem;
• processos de troca de produtos;
• aplicações de apoio às rotinas operacionais das lojas.
Estas soluções partilhavam a mesma premissa arquitetural: ligar sistemas corporativos, canais digitais eoperação física através de serviços desacoplados e comunicação orientada a eventos.
O principal resultado da iniciativa não foi apenas a redução significativa do tempo de sincronização dos stocks.
A transformação permitiu utilizar o stock distribuído pelas aproximadamente 1.800 lojas como parte efetiva da estratégia digital da organização.
Ao aproximar SAP, lojas físicas, aplicações operacionais e e-commerce, a arquitetura criou as bases para uma operação verdadeiramente omnicanal, na qual o cliente podia iniciar a sua jornada num canal e concluí-la noutro.
Mais do que integrar stocks, o projeto transformou a rede de lojas numa extensão da plataforma decomércio digital.