No panorama Fintech de 2026, a expectativa do utilizador é o imediatismo. Já não é aceitável esperar dias por um feedback preliminar sobre um pedido de financiamento. Aqui entra em jogo a Event-Driven Architecture: Gestão em Tempo Real do processamento de processos, um paradigma que transforma processos bancários monolíticos e lentos em fluxos de dados reativos e escaláveis. Este artigo técnico explora como conceber um sistema distribuído capaz de gerir o ciclo de vida de um crédito habitação, garantindo resiliência e consistência dos dados.

1. O Problema: Limites das Arquiteturas Request/Response no Crédito Habitação

Tradicionalmente, a orquestração de um processo de crédito habitação ocorria através de arquiteturas monolíticas ou microsserviços acoplados via HTTP (REST/gRPC). Esta abordagem apresenta críticas estruturais:

• Acoplamento Temporal: Se o serviço de Credit Scoring for lento, todo o processo de pedido bloqueia, deixando o utilizador à espera em frente a um ícone de carregamento.
• Polling Ineficiente: Os sistemas downstream devem interrogar continuamente a base de dados central para saber se existem novos processos para trabalhar (“Are we there yet?”), desperdiçando recursos computacionais.
• Gestão de Erros: Numa cadeia de chamadas síncronas, a falha de um serviço periférico (ex: o gerador de PDF) pode fazer falhar toda a transação.

2. A Solução: Event-Driven Architecture (EDA)

Numa arquitetura orientada a eventos, os microsserviços não falam diretamente entre si. Em vez disso, produzem e consomem eventos. Um evento é um facto imutável ocorrido no passado (ex: MortgageApplicationSubmitted).

Componentes Chave da Arquitetura

Para o nosso caso de uso, compararemos dois backbones tecnológicos dominantes:

• Apache Kafka: Ideal para throughputs elevados e quando é necessária a Log Retention para reprocessar os eventos (Replayability). É a escolha preferida para os bancos que necessitam de um audit trail imutável on-premise ou híbrido.
• Amazon EventBridge: Solução Serverless perfeita para o routing inteligente de eventos na cloud AWS. Reduz o operational overhead mas tem limites na dimensão do payload e na retenção em comparação com o Kafka.

Decisão Arquitetural: Para um sistema de crédito habitação complexo que requer historicização e auditorias rigorosas, utilizaremos Apache Kafka como Event Bus central, integrando padrões de Schema Registry (ex: Avro ou Protobuf) para garantir a compatibilidade dos contratos de dados.

3. Conceção do Fluxo: Coreografia vs Orquestração

A gestão de um processo de crédito habitação é um Long-Running Process. Devemos decidir como coordenar os serviços:

Microsserviços Envolvidos

1. Application Service: Recebe o pedido do utilizador.
2. Scoring Service: Avalia o risco de crédito (Crif, Experian).
3. Document Service: Gere o upload e validação OCR dos documentos.
4. Bank Gateway: Comunica com os sistemas legacy do banco para a decisão final.
5. Notification Service: Envia email/SMS/Push ao utilizador.

Utilizaremos uma abordagem híbrida: Coreografia para os eventos de estado (pub/sub) e Orquestração (através do padrão Saga) para a gestão da consistência transacional.

4. Gestão da Consistência: O Padrão Saga

Num sistema distribuído, não podemos usar as transações ACID da base de dados local para processos que atravessam vários serviços. Devemos abraçar a Eventual Consistency. Mas o que acontece se o Bank Gateway recusar o processo depois de o Scoring Service o ter aprovado?

Devemos implementar o Padrão Saga para gerir os rollbacks (transações de compensação).

Exemplo de Fluxo Saga (Coreografia)

Imaginemos o fluxo ideal e o fluxo de falha:

Passo 1: Início da Transação

O utilizador envia o pedido. O Application Service publica o evento:

{
  "eventId": "uuid-1234",
  "eventType": "MortgageApplicationSubmitted",
  "payload": {
    "applicationId": "M-999",
    "amount": 200000,
    "applicant": "Mario Rossi"
  }
}

Passo 2: Processamento Paralelo

O Scoring Service e o Document Service escutam o evento. O Scoring Service aprova e publica CreditScoreApproved. O Document Service valida os PDFs e publica DocumentsValidated.

Passo 3: Agregação e Decisão

O Bank Gateway aguarda ambos os eventos. Uma vez recebidos, tenta finalizar o processo no mainframe bancário.

Passo 4: Falha e Compensação (Rollback)

Se o mainframe responder com um erro (ex: “Fundos insuficientes” ou “Timeout”), o Bank Gateway publica o evento MortgageFinalizationFailed.

Neste ponto, são acionadas as Compensating Transactions:

• O Scoring Service escuta a falha e liberta eventuais “bloqueios” no rating de crédito do utilizador.
• O Application Service escuta a falha e atualiza o estado do processo de “Em Processamento” para “Recusado”, notificando o utilizador.

5. Detalhes Técnicos e Melhores Práticas

Idempotência

No Kafka, a entrega exactly-once é complexa. É mais seguro projetar os consumidores para serem idempotentes. Se o Notification Service receber duas vezes o evento MortgageApproved, deve ser capaz de perceber (através de um ID único do evento guardado no Redis ou DB) que já enviou o email e descartar o duplicado.

Dead Letter Queues (DLQ)

O que acontece se um evento estiver malformado e fizer o consumidor falhar? Não podemos bloquear a fila. O evento problemático deve ser movido para uma Dead Letter Queue após X tentativas falhadas, permitindo à equipa de engenharia analisá-lo manualmente sem parar o fluxo dos outros processos.

Schema Evolution

Os processos de crédito habitação mudam com o tempo (novas normativas, novos campos de dados). Utilizar um Schema Registry é fundamental. Os produtores e os consumidores devem concordar sobre o esquema (ex: Avro). Se adicionarmos o campo taxa_juro_bonificada, os consumidores antigos não devem falhar (backward compatibility).

6. Implementação: Snippet de Configuração Kafka (Java/Spring Boot)

Aqui está um exemplo de como configurar um consumer que suporta a gestão de transações num contexto Spring Cloud Stream:

@Bean
public Consumer<MortgageEvent> mortgageProcessor() {
    return event -> {
        if (event.getType().equals("MortgageApplicationSubmitted")) {
            try {
                scoringService.calculate(event.getPayload());
            } catch (Exception e) {
                // Lógica de envio para DLQ ou retry automático
                throw new AmqpRejectAndDontRequeueException(e);
            }
        }
    };
}

7. Conclusões

Passar para uma arquitetura de eventos para a gestão de crédito habitação não é apenas um exercício de estilo tecnológico, mas uma necessidade de negócio. Permite desacoplar as equipas de desenvolvimento (a equipa “Documentos” pode lançar atualizações sem se coordenar com a equipa “Banca”), escalar os serviços de forma independente (mais recursos para o Scoring durante os picos de pedidos) e oferecer ao utilizador final uma experiência fluida e transparente.

A complexidade introduzida pela gestão da consistência eventual e pelos padrões de compensação é o preço a pagar para obter um sistema resiliente, capaz de gerir volumes elevados sem os gargalos das bases de dados relacionais centralizadas.

Perguntas frequentes