Construindo a Customer Data Platform do Grupo SBF

Salve Salve Família!
Bão demais?

O objetivo deste artigo é compartilhar um pouco do processo de Discovery, Decisões Arquiteturais e de Design na construção da Customer Data Platform (CDP) do Grupo SBF.

De início gostaria de dar um breve resumo sobre o que é uma CDP e qual problema resolve.

A CDP é uma aplicação capaz de ingerir dados de qualquer fonte, criar perfis unificados de clientes com os dados capturados e compartilhar/distribuir dados para qualquer sistema em tempo real (especialmente CRM e sistemas de marketing). Com certeza, algo crucial para continuarmos na direção de Data Driven e Customer Centric.

Aqui no Grupo SBF identificamos a necessidade de uma solução que pudesse compor o perfil do cliente consolidando dados de diferentes fontes para que, conhecendo melhor seus hábitos e preferências, pudéssemos oferecer uma experiência personalizada em qualquer ponto de contato.

Fizemos alguns benchmarks e reuniões com fornecedores de CDP, e depois de algumas reuniões analisando trade-offs, tomamos a decisão de construir uma solução interna.

Decidimos que nosso MVP seria criar uma visão do cliente Centauro agnóstica ao canal de origem (Digital/E-commerce e Loja Física). Em outras palavras, nosso objetivo era disponibilizar uma visão unificada de todas as compras realizadas dos nossos clientes tanto em loja física como no e-commerce.

Depois de alguns discoveries, fluxogramas e entendimento do primeiro caso de uso, precisávamos tomar algumas decisões sobre arquitetura e design da solução. Tentei listar as decisões mais importantes e uma ideia do motivo da escolha para cada uma delas.

Event Sourcing

Devido ao problema que precisaríamos resolver e algumas necessidades de negócio, chegamos à conclusão de que o padrão Event Sourcing cairia muito bem no nosso cenário.

Uma característica que queríamos, por exemplo, era de ter a possibilidade de reconstruir o estado de um cliente a qualquer momento e quando quiséssemos. Outra necessidade era a de dar pesos para a origem dos dados, por exemplo, os dados do e-commerce ter prioridade sobre os dados de loja física. Tratar as ações do cliente como eventos e a compilação/unificação num outro momento, facilitou o design da aplicação.

NoSQL

Pensando na pluralidade de eventos/schemas que teríamos que consumir de outras plataformas/ferramentas e também na flexibilidade para evolução da solução, decidimos escolher por um banco NoSQL. Nossa escolha foi de utilizar o MongoDB.

Num primeiro momento, fizemos alguns testes utilizando a feature de Aggregation do Mongo, mas devido a complexidade e evolução das nossas regras, acabamos decidindo por implementar a unificação dos dados na própria aplicação.

Outro ponto importante está relacionado ao volume de dados que seriam armazenados e a possibilidade de configuração de Sharding no cluster.

Message Broker

Uma das necessidades/expectativas para nossa solução era de termos essas informações em tempo real ou algo próximo a isso. Com isso em mente e também com alguns objetivos de resiliência, escalabilidade, throughput e também com a evolução da plataforma de tecnologia do grupo caminhando para um cenário mais coreografado nas interações, decidimos utilizar um message broker para centralizar/intermediar nossas comunicações. Nossa escolha foi de utilizar o Kafka.

Por ser uma aplicação de muitos dados e com a certeza da evolução do conteúdo das mensagens, decidimos utilizar Schema Registry e Avro na serialização da mensagem ao postar no kafka, assim tornando mais seguro o consumo das mensagens geradas pela aplicação.

Importante dizer que não descartamos a possibilidade de recebermos a ingestão de outros/novos dados de outras formas como: API, CSV, etc.

Tecnologia

Para a escolha da tecnologia, de largada chegamos no consenso que seria interessante utilizar alguma linguagem estaticamente tipada. Com isso, nos baseamos na experiência dos integrantes do time, ecossistema, comunidade e mais alguns pontos e decidimos por utilizar Kotlin com Spring Boot.

Até agora, a escolha do Kotlin tem se mostrado bastante interessante, muito devido a features como: Data Classes e novas features como Inline Classes que tem nos ajudado principalmente na criação de Value Objects, por exemplo. Sem contar a robustez e estabilidade da JVM e o ecossistema Java.

Segue imagem detalhando um pouco mais o fluxo de dados e integrações:

Conclusão

Com o ownership da solução, temos a liberdade para testarmos várias possibilidades. Por exemplo, atualmente a forma de acesso às informações da CDP acontecem de duas formas: Rest API e tópicos no kafka, onde quando ocorrem atualizações, postamos o dado filtrado/padronizado/unificado no kafka para consumos de outras aplicações, por exemplo, o envio para nosso Lake.

Com esse ownership, por exemplo, temos a possibilidade de criarmos um endpoint GraphQL para facilitar o uso e autonomia dos clientes da API disponibilizada. Fora outras melhorias/evoluções que se tornam possíveis.

Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte do nosso time! Você pode conferir nossas vagas aqui.