Do Stream para o Banco: Processando Market Data com Spring Boot, Redis e Flyway

Olá, pessoal!

No último post, vimos como nosso serviço em Python coleta dados da B3 e os publica no Kafka. Hoje, vamos dar um passo crucial: consumir esses dados e torná-los úteis para a nossa corretora.

Vou apresentar a Broker Asset API, o microserviço Java responsável por gerenciar o catálogo de ativos, manter os preços atualizados e servir essas informações com baixíssima latência.

---

🎯 Foco no MVP (Minimum Viable Product)

Antes de mergulharmos no código, vale um disclaimer: estamos construindo a base. Nesta fase, o objetivo é garantir que o fluxo "ponta a ponta" funcione.

O foco agora é a entrega de valor central: ter o dado disponível e performático. Futuramente, voltaremos a este serviço para adicionar testes unitários, refinamento de exceções e maior resiliência.

---

🏗️ Os Pilares da Asset API

Para este MVP, foquei em quatro pontos principais de implementação:

1. Evolução de Banco de Dados com Flyway

Para garantir que o esquema do nosso banco MySQL seja versionado e replicável, utilizei o Flyway. Criamos a tabela assets que armazena o ticker, nome, preço atual e o status do ativo.

• Destaque técnico: O uso de um índice no campo ticker garante que as consultas por símbolo sejam extremamente rápidas.

2. Consumidor Kafka: Reatividade em Tempo Real

A API "escuta" o tópico trading-assets-market-data-v1. Assim que o serviço Python publica um novo preço, nosso consumidor captura a mensagem e inicia o fluxo de atualização.

• Garantia de Ordem: Como usamos o ticker como chave no Kafka, processamos as atualizações na ordem correta em que foram geradas.

    @KafkaListener(
            topics = "trading-assets-market-data-v1",
            groupId = "broker-asset-api"
    )
    public void consume(AssetMarketDataDTO dto) {
        log.info("Received market data for: {}", dto.getTicker());

        assetService.updateAsset(dto);
    }

3. Service Layer: Persistência Híbrida (SQL + Redis)

O AssetService é onde a lógica de negócio reside. Ao receber um novo preço, ele realiza duas operações:

1. Persistência no MySQL: Atualiza o registro do ativo (ou cria um novo, caso não exista) para garantir a consistência dos dados.

1. Atualização de Cache (Redis): O preço é enviado para um cache no Redis com a chave market:price:{ticker}.
2. Isso permite que outros componentes do sistema consultem o preço instantaneamente sem sobrecarregar o banco de dados relacional.

4. Controller: Disponibilizando a Informação

Criamos endpoints REST para que outros serviços ou o front-end consultem o catálogo de ativos:

• GET /api/v1/assets: Lista todos os ativos ativos disponíveis.
• GET /api/v1/assets/{ticker}: Retorna os detalhes e o preço atualizado de um ativo específico.

---

🛠️ O que vem a seguir?

Este microserviço de Assets é a fundação que garante que o sistema saiba "o que" está sendo negociado e "por quanto". Como estamos seguindo a estratégia de MVP, o foco foi estabelecer esse contrato de dados e a persistência básica.

Mas um ativo sozinho não faz uma corretora. Ele precisa pertencer a alguém.

No próximo post, vamos subir um degrau na complexidade e falar sobre a Broker Wallet API. Vamos entender como:

• Gerenciar o saldo financeiro do usuário.
• Vincular a custódia dos ativos às carteiras dos clientes.
• Como o sistema se prepara para refletir as variações de mercado no patrimônio do investidor.

O que achou dessa abordagem de construir o ecossistema peça por peça? Deixe suas dúvidas nos comentários!

---

​🔎​ Sobre a série

⬅️ Post Anterior: Dica de ferramentas.

📘​ Índice da Série: Guia da Série.

---

Links:

• LinkedIn
• GitHub