Investimento de 1,5 bilhão da Edenred: o que muda na infraestrutura de dados

A Edenred decidiu aplicar quase 1,5 bilhão de euros em produtos digitais, infraestrutura tecnológica e soluções de dados e inteligência artificial entre 2022 e 2025. O movimento não é apenas sobre lançar novas funcionalidades. Ele revela o tamanho da base de transações que a empresa precisa sustentar em tempo real em vários países.

No meu time na UNODATA já acompanhamos projetos semelhantes. Quando uma plataforma de pagamentos ou benefícios cresce rápido, o primeiro gargalo quase nunca aparece no código da aplicação. Ele surge na camada de armazenamento, na rede que liga os datacenters e na capacidade de observar o que realmente está acontecendo quando o volume sobe.

O que mais me chamou atenção no anúncio foi a ênfase em “base global de dados”. Isso significa que a Edenred está unificando ou pelo menos conectando bases que antes viviam separadas por região. Essa consolidação traz ganhos de análise, mas também aumenta a complexidade operacional.

O que um investimento desse tamanho realmente exige de infraestrutura

Plataformas que processam benefícios e pagamentos em tempo real precisam de latência baixa e consistência forte. Quando o volume de eventos cresce, o custo de cada milissegundo extra de latência vira dinheiro perdido ou transação rejeitada.

Em projetos que acompanhamos, o principal desafio não é comprar mais servidores. É projetar a topologia de rede e o modelo de dados para que a replicação entre regiões não vire um ponto de falha. Muitos times descobrem isso tarde, quando o primeiro incidente de partição de rede acontece durante um pico de uso.

A Edenred também fala em soluções baseadas em IA. Modelos de detecção de fraude ou recomendação de benefícios consomem bastante recurso de CPU e memória. Colocar esses modelos em produção exige uma camada de inferência separada, com dimensionamento automático e rollback rápido caso a precisão caia.

Observabilidade em ambientes que misturam transações e modelos de IA

Observabilidade não é só coletar métricas. É conseguir correlacionar um aumento de latência em um endpoint de pagamento com o comportamento de um modelo de machine learning que roda em outro cluster. Sem essa correlação, o time de suporte passa horas chutando hipóteses.

Na prática, recomendo separar três planos de telemetria: métricas de infraestrutura, traces de transações de negócio e logs estruturados dos modelos de IA. Quando esses três planos conversam entre si, o tempo médio de recuperação de incidentes cai bastante.

• Monitore latência de inferência separada da latência da aplicação principal.
• Registre features de entrada e saída dos modelos para auditoria posterior.
• Mantenha amostragem de traces em 100% durante picos, mesmo que isso custe mais armazenamento.
• Tenha runbooks que incluam rollback de modelo, não só de código.

Esses quatro pontos parecem básicos, mas são os que mais vemos faltando quando o sistema começa a escalar.

Quando a base de dados vira global, o tempo de recuperação de incidentes depende menos de hardware e mais da qualidade dos traces que você consegue correlacionar em minutos.

Lições práticas para times de suporte e sysadmin

Times que operam plataformas semelhantes à da Edenred aprendem rápido que o maior custo não é a nuvem em si. É o tempo que a equipe gasta investigando incidentes que poderiam ter sido evitados com instrumentação melhor.

Uma mudança que vale a pena fazer agora é revisar a retenção de logs de transações. Muitos ambientes guardam apenas sete dias. Quando surge uma suspeita de fraude ou uma auditoria, sete dias raramente são suficientes. Aumentar essa janela para trinta ou noventa dias, com compressão adequada, costuma ser mais barato do que parece.

Outra lição é tratar o pipeline de dados como um produto. Quem consome os dados para treinar modelos de IA precisa de SLAs claros de entrega e qualidade. Sem isso, o time de ciência de dados passa mais tempo limpando dados do que gerando valor.

O que ainda falta discutir em investimentos grandes como esse

O anúncio da Edenred é claro sobre o valor investido, mas não detalha a arquitetura que será usada. Essa falta de detalhe é comum e compreensível por razões competitivas. Ainda assim, times de infraestrutura fariam bem em acompanhar os próximos relatórios técnicos da empresa.

O mais importante agora não é copiar o valor investido. É entender quais decisões de arquitetura permitiram que esse dinheiro fosse gasto de forma eficiente. Quem conseguir separar o que é marketing do que é lição técnica sai na frente.

Perguntas frequentes

Quanto desse investimento vai realmente para infraestrutura física?

A maior parte costuma ir para nuvem e ferramentas de dados, mas ainda é necessário provisionar capacidade de rede e armazenamento local em regiões críticas para reduzir latência.

Como medir se a observabilidade está adequada antes do próximo pico?

Teste com injeção de falhas em ambiente de staging e verifique se o time consegue identificar a causa raiz em menos de quinze minutos usando apenas os dashboards existentes.

Qual o maior risco quando se consolida bases de dados globais?

O risco principal é a replicação inconsistente durante partições de rede. Ter um plano de resolução de conflitos bem testado é mais importante que o volume de dados replicados.

Vale a pena aumentar retenção de logs para noventa dias?

Sim, especialmente em ambientes regulados. O custo de armazenamento comprimido costuma ser menor que o custo de uma auditoria ou incidente que não consegue ser investigado por falta de histórico.