No varejo moderno, detectar uma fraude D+1 (no dia seguinte) é apenas contabilidade de perdas. O objetivo é bloquear a transação suspeita antes que ela seja concluída. Neste tutorial, mostramos como usar Apache Flink para detecção de padrões complexos (CEP) em milissegundos.
O Cenário
Imagine um padrão de ataque comum: "Teste de Cartão". O fraudador faz uma compra pequena (R$ 1,00) para ver se o cartão é válido, e logo em seguida tenta uma compra grande (R$ 5.000,00). Regras estáticas em bancos de dados relacionais sofrem para correlacionar esses eventos em tempo real sob alta carga.
A Solução com Flink SQL
Apache Flink permite definir janelas de tempo e padrões de sequência. Podemos escrever uma query SQL que diz: "Alerte-me se um usuário fizer mais de 3 transações em 1 minuto, OU se fizer uma transação pequena seguida de uma grande em menos de 5 minutos, vindo de IPs diferentes".
SELECT *
FROM transactions
MATCH_RECOGNIZE (
PARTITION BY card_id
ORDER BY transaction_time
MEASURES
A.amount AS first_amount,
B.amount AS second_amount
ONE ROW PER MATCH
PATTERN (A B)
DEFINE
A AS A.amount < 5.00,
B AS B.amount > 1000.00 AND B.transaction_time < A.transaction_time + INTERVAL '5' MINUTE
)Enriquecimento de Dados
O Flink não olha apenas para o stream bruto. Ele pode fazer joins com tabelas de dimensão (ex: perfil do cliente) carregadas em memória. Isso permite adicionar contexto: "Esta transação é anômala para ESTE cliente específico?".
Latência vs. Throughput
Em nossos testes de carga na Intelium, um cluster Flink de tamanho médio processou 50.000 eventos por segundo com latência p99 abaixo de 20ms. Isso é rápido o suficiente para estar no caminho crítico da autorização de pagamento sem degradar a experiência do usuário.
Conclusão
Stream Processing evoluiu de apenas "mover dados" para "tomar decisões". Com Flink, a lógica de negócio complexa sai do código da aplicação (microserviços) e vai para a infraestrutura de dados, onde pode ser escalada e gerenciada de forma centralizada e eficiente.