No panorama financeiro atual, a velocidade e a fiabilidade não são simples funcionalidades, mas requisitos de conformidade. Conceber um sistema de gestão de clientes (CRM) para o setor Fintech exige uma mudança de paradigma em relação aos sistemas monolíticos tradicionais baseados em bases de dados relacionais e chamadas síncronas. Neste guia técnico, baseado na experiência de desenvolvimento do sistema BOMA, exploraremos como uma arquitetura event-driven na Google Cloud Platform (GCP) pode resolver os desafios de escalabilidade, coerência e reatividade típicos do setor.

Porquê uma Arquitetura Event-Driven na Fintech?

Um CRM Fintech não se limita a armazenar registos. Deve reagir em tempo real a depósitos, alterações de estado KYC (Know Your Customer), flutuações de mercado e interações do utilizador. Uma abordagem tradicional Request/Response (HTTP síncrono) cria um acoplamento forte entre os serviços, levando a gargalos e potenciais falhas em cadeia.

A arquitetura event-driven (EDA) inverte este modelo. Em vez de serviços que se chamam diretamente, os componentes emitem “eventos” (factos ocorridos, como PaymentReceived ou LeadCreated) que são consumidos assincronamente por outros serviços. Segundo a documentação da Google Cloud Architecture, este padrão melhora drasticamente a resiliência e a escalabilidade do sistema.

O Stack Tecnológico GCP: O Caso BOMA

Para o projeto BOMA, a escolha do stack tecnológico recaiu sobre serviços geridos serverless para minimizar o overhead operacional e maximizar a escalabilidade:

• Google Pub/Sub: O backbone de mensagens para a ingestão e distribuição dos eventos.
• Cloud Functions (2nd Gen): Camada de computação para executar a lógica de negócio em resposta aos eventos.
• Firestore: Base de dados NoSQL documental para o estado da aplicação e atualizações em tempo real.
• BigQuery: Data warehouse para a análise histórica e relatórios de conformidade.

1. Desacoplamento com Google Pub/Sub

O coração da arquitetura é o Google Pub/Sub. Cada ação significativa no CRM é publicada como mensagem num Tópico específico.

Padrão de Implementação

Imaginemos o fluxo de um novo utilizador que se regista:

1. O frontend chama uma API Gateway.
2. A API publica um evento no tópico user-onboarding.
3. O Pub/Sub garante a persistência da mensagem e responde imediatamente ao cliente (baixa latência).

Neste ponto, várias Subscrições ativam workers independentes:

• Sub A (CRM Core): Cria o perfil no Firestore.
• Sub B (Compliance): Inicia os controlos de branqueamento de capitais (AML) através de um fornecedor externo.
• Sub C (Notification): Envia o email de boas-vindas.

Best Practice Técnica: Na Fintech, a ordem dos eventos é crítica (não pode levantar fundos antes de os ter depositado). Utilizamos as Ordering Keys do Pub/Sub (ex. o ID do utilizador) para garantir que as mensagens relativas ao mesmo cliente sejam processadas em ordem sequencial, mantendo a escalabilidade paralela em utilizadores diferentes.

2. Firestore: Base de Dados Documental e Real-Time

A escolha do Firestore em detrimento do Cloud SQL é ditada pela necessidade de atualizações em tempo real no dashboard dos operadores do CRM. O Firestore utiliza listeners (snapshot listeners) que permitem ao frontend atualizar-se automaticamente quando um documento muda, sem necessidade de polling contínuo.

Modelação de Dados para Fintech

Embora o Firestore seja NoSQL, a estrutura dos dados deve ser rigorosa. Uma estrutura típica para um CRM Fintech poderia ser:

/users/{userId}
    - profileData (Map)
    - kycStatus (String)
    /transactions/{transactionId}
        - amount (Number)
        - currency (String)
        - status (String)
        - timestamp (Timestamp)

Atenção ao Hotspotting: Evite usar timestamps ou IDs sequenciais como chaves dos documentos se prevê escritas massivas (>500/seg), pois isso concentra a carga num único intervalo de chaves. Utilize IDs gerados aleatoriamente ou hashes.

3. Lógica Serverless com Cloud Functions

As Cloud Functions atuam como a cola entre o Pub/Sub e o Firestore. Cada função é um microsserviço atómico com uma responsabilidade única.

Exemplo: Gestão de Mudança de Estado Prática

Quando um controlo KYC é concluído, um evento KycCompleted ativa uma Cloud Function. Esta função:

1. Lê o payload do evento.
2. Executa uma Transação Firestore para atualizar o estado do utilizador de PENDING para APPROVED.
3. Publica um novo evento UserActive para desbloquear as funcionalidades de trading.

4. O Desafio da Coerência: Idempotência e Transações

Esta é a secção mais crítica para um CTO ou um Lead Engineer. Os sistemas distribuídos como o Pub/Sub garantem uma entrega “at-least-once” (pelo menos uma vez). Isto significa que, raramente, a sua Cloud Function poderá receber o mesmo evento de pagamento duas vezes.

Solução: Idempotência

Para evitar débitos duplos ou estados corrompidos, cada operação deve ser idempotente. Eis como implementá-lo no Firestore:

1. Cada evento Pub/Sub deve ter um eventId único (gerado na fonte).
2. Dentro da transação Firestore, verifique se o eventId já foi processado numa coleção de suporte processed_events.
3. Se existir, a função termina com sucesso sem fazer nada (o sistema reconhece o evento como já gerido).
4. Se não existir, a função executa a lógica de negócio e escreve o eventId na coleção de suporte, tudo atomicamente.

Esta abordagem garante a integridade dos dados financeiros mesmo em caso de retries automáticos por parte da infraestrutura Google.

5. Analytics Avançada com BigQuery

Um CRM não serve apenas para gerir, mas para compreender. Os dados operacionais no Firestore não estão otimizados para queries analíticas complexas (ex. “Qual é a taxa de conversão média por região no último trimestre?”).

Para isso, implementamos uma pipeline de streaming para o BigQuery. Podemos utilizar a extensão oficial “Stream Firestore to BigQuery” ou uma Cloud Function dedicada que escuta as alterações no Firestore e insere os dados em tabelas particionadas no BigQuery.

Isto permite à equipa de Data Science analisar os funis de conversão e o comportamento dos utilizadores sem impactar o desempenho da base de dados operacional do CRM.

Conclusões

Construir um CRM Fintech com uma arquitetura event-driven na Google Cloud oferece vantagens inegáveis em termos de desacoplamento e escalabilidade. No entanto, desloca a complexidade da gestão da infraestrutura para a gestão da lógica aplicacional (gestão de erros, idempotência, consistência eventual).

Seguindo os padrões descritos — o uso rigoroso do Pub/Sub para o buffering, Firestore para o estado em tempo real e controlos de idempotência transacionais — é possível criar um sistema robusto capaz de gerir os volumes e a criticidade das aplicações financeiras modernas.

Perguntas frequentes