DEV Community: Roberto de Vargas Neto

From Stream to Database: Processing Market Data with Spring Boot, Redis, and Flyway

Roberto de Vargas Neto — Wed, 01 Apr 2026 20:34:52 +0000

Hello everyone!

In my last post, we saw how our Python service collects B3 data and publishes it to Kafka. Today, we take a crucial step: consuming this data and making it useful for our brokerage ecosystem.

I’ll introduce the Broker Asset API, the Java microservice responsible for managing the asset catalog, keeping prices updated, and serving this information with ultra-low latency.

🎯 MVP Focus (Minimum Viable Product)

Before diving into the code, a quick disclaimer: we are building the foundation. At this stage, the goal is to ensure the end-to-end flow works seamlessly.

The focus is on delivering core value: making data available and performant. In the future, we will revisit this service to add unit tests, refine exception handling, and increase resilience.

🏗️ The Pillars of the Asset API

For this MVP, I focused on four main implementation points:

1. Database Evolution with Flyway

To ensure our MySQL schema is versioned and reproducible, I used Flyway. We created the assets table to store the ticker, name, current price, and asset status.

Technical Highlight: Using an index on the ticker field ensures that symbol-based queries are extremely fast.

2. Kafka Consumer: Real-Time Reactivity

The API "listens" to the trading-assets-market-data-v1 topic. As soon as the Python service publishes a new price, our consumer captures the message and triggers the update flow.

Ordering Guarantee: Since we use the ticker as the Kafka key, we process updates in the exact order they were generated.

    @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: Hybrid Persistence (SQL + Redis)

The AssetService is where the business logic resides. Upon receiving a new price, it performs two operations:

MySQL Persistence: Updates the asset record (or creates a new one) to ensure data consistency.

Cache Update (Redis): The price is sent to a Redis cache with the key market:price:{ticker}.
This allows other system components to query prices instantly without overloading the relational database.

4. Controller: Serving the Information

We created REST endpoints so that other services or the front-end can query the asset catalog:

GET /api/v1/assets: Lists all available active assets.
GET /api/v1/assets/{ticker}: Returns details and the updated price for a specific asset.

🛠️ What’s Next?

The Asset microservice is the foundation that ensures the system knows "what" is being traded and "for how much." Since we are following an MVP strategy, the focus was on establishing this data contract and basic persistence.

But an asset alone doesn't make a brokerage. It needs to belong to someone.

In the next post, we’ll increase the complexity and talk about the Broker Wallet API. We will explore:

Managing user financial balances.
Linking asset custody to customer wallets.
How the system reflects market variations in the investor's equity.

What do you think of this step-by-step approach to building an ecosystem? Let me know your thoughts in the comments!

🔎 About the series

⬅️ Previous Post: Tooling Tips.

📘 Series Index: Series Guide.

Links:

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

Roberto de Vargas Neto — Sat, 28 Mar 2026 14:44:22 +0000

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:

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

Atualização de Cache (Redis): O preço é enviado para um cache no Redis com a chave market:price:{ticker}.
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:

Tooling Tips: Visualizing Your Data in MongoDB and Kafka

Roberto de Vargas Neto — Sun, 15 Mar 2026 12:36:10 +0000

Hello, everyone!

When developing distributed systems like My Broker B3, you often find yourself "working blindly" if you don't have the right tools to validate what’s happening inside your containers.

Today, I want to share two essential tools I’m using to ensure that the market data fetched with Python is correctly reaching the database and the message broker.

1. MongoDB Compass: The Official MongoDB GUI

Even though MongoDB is running in an isolated environment via Docker, MongoDB Compass is the tool I use to "see" the documents saved by the Market Data microservice.

What it solves: It allows me to validate if the data mapping in Python worked correctly and if fields like created_at and price are in the expected format.
How to connect to Docker:
- Connection String: mongodb://localhost:27017 (Ensure that port 27017 matches the one mapped in your docker-compose.yml).
Pro Tip: In Compass, you can visualize the price_history collection in either tabular or JSON format, which makes quick inspections much easier.

📸 Viewing in document mode:

📸 Table view:

2. Offset Explorer (Formerly Kafka Tool)

Kafka can be intimidating to manage via the command line (CLI). Offset Explorer is a desktop client that makes visualizing messages within your topics incredibly easy.

What it solves: It allows me to monitor, in real-time, the messages arriving in the trading-assets-market-data-v1 topic.
Configuration for the Docker environment:
- Cluster Name: MyBrokerKafka (or any name you prefer).
- Zookeeper/Broker: localhost:9092.

Crucial Tip: To read the message content sent as JSON from Python, go to the tool's settings and change the Content Type (for both Key and Value) from Byte Array to String. This ensures the data is displayed in a human-readable format.

📸 Visualizando as mensagens

💡 Why is this important?

Mastering these support tools significantly speeds up the development cycle. In our case, Offset Explorer was essential to validate one of the project's most important decisions: using the Ticker as the message key in Kafka to ensure per-asset ordering.

🚀 Conclusion

Having full visibility over your data is the first step toward building resilient systems. In the next post of the main series, we will head back to the Java ecosystem to start consuming these events!

What about you? What tools do you use to debug your distributed systems? Let me know in the comments!

🔎 About the series

⬅️ Previous Post: Market Data Integrator.

📘 Series Index: Series Guide.

Links:

Dica de Ferramentas: Como Visualizar seus Dados no MongoDB e Kafka

Roberto de Vargas Neto — Sun, 15 Mar 2026 12:02:53 +0000

Olá, pessoal!

Ao desenvolver sistemas distribuídos como o My Broker B3, muitas vezes trabalhamos "às cegas" se não tivermos as ferramentas certas para validar o que acontece dentro dos nossos containers.

Hoje, quero compartilhar duas ferramentas essenciais que estou utilizando para garantir que os dados de mercado que busco com Python estejam chegando corretamente ao banco de dados e ao broker de mensagens.

1. MongoDB Compass: O GUI Oficial do MongoDB

Embora o MongoDB esteja rodando de forma isolada no Docker, o MongoDB Compass é a ferramenta que utilizo para "enxergar" os documentos salvos pelo microserviço de Market Data.

O que ele resolve: Permite validar se o mapeamento de dados no Python funcionou e se campos como created_at e price estão no formato esperado.
Como conectar ao Docker:
- Connection String: mongodb://localhost:27017 (Certifique-se de que a porta 27017 é a que você mapeou no seu docker-compose.yml).
Dica de uso: No Compass, você pode visualizar o histórico de preços na coleção price_history de forma tabular ou em formato JSON, o que facilita muito a conferência rápida.

📸 Visualização em modo documento:

📸 Visualização em modo tabela:

2. Offset Explorer (Antigo Kafka Tool)

O Kafka pode ser intimidador para gerenciar via linha de comando. O Offset Explorer é um cliente desktop que facilita absurdamente a visualização das mensagens dentro dos tópicos.

O que ele resolve: Permite ver em tempo real as mensagens chegando no tópico trading-assets-market-data-v1.
Configuração para o ambiente Docker:
- Cluster Name: MyBrokerKafka (ou o nome de sua preferência).
- Zookeeper/Broker: localhost:9092.

Dica Crucial: Para conseguir ler o conteúdo das mensagens que enviamos como JSON via Python, vá nas configurações da ferramenta e altere o Content Type (Key e Value) de Byte Array para String.

📸 Visualizando as mensagens

💡 Por que isso é importante?

Dominar essas ferramentas de suporte acelera muito o ciclo de desenvolvimento. No nosso caso, o Offset Explorer foi fundamental para validar uma das decisões mais importantes do projeto: o uso do Ticker como chave (key) da mensagem no Kafka para garantir a ordenação dos preços por ativo.

🚀 Conclusão

Ter visibilidade sobre seus dados é o primeiro passo para construir sistemas resilientes. No próximo post da série principal, voltaremos ao ecossistema Java para começar a consumir esses eventos!

Gostou da dica? Quais ferramentas você costuma usar para depurar seus sistemas distribuídos?

🔎 Sobre a série

⬅️ Post Anterior: Integrador de Market Data.

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

Links:

Market Data Integrator: Consuming Real-Time Data with Python, MongoDB, and Kafka

Roberto de Vargas Neto — Sat, 14 Mar 2026 20:48:15 +0000

Hello, everyone!

Continuing the My Broker B3 series, today let's talk about the component that feeds the entire ecosystem with real-time data from the Brazilian financial market: The Broker Market Data API.

This Python-based microservice acts as an ingestor, connecting the external world (Brappi API) to our internal infrastructure.

🏗️ The Solution and Data Flow

The main objective is to ensure that asset prices are always up to date for other services. The data flow was designed in three main steps:

Scheduled Ingestion: The service iterates through a Watchlist of 50 assets, including Blue Chips (such as PETR4 and VALE3), REITs (FIIs), and ETFs.
Historical Persistence (MongoDB): Before any processing, the complete payload is saved in MongoDB (broker_market_data_db). This ensures we have an audit trail and data for future analysis.
Event Streaming (Kafka): The updated price is published to the trading-assets-market-data-v1 topic. This allows any other microservice to react to these changes in real time.

🛠️ Implementation Details

I chose Python 3.12 for this component due to its efficiency in handling HTTP requests and its excellent ecosystem for data integration.

The Importance of the Kafka Message Key

A vital technical decision in this service was using the asset ticker as the message key when publishing to Kafka.

Why is this important?
Kafka guarantees message ordering only within a single partition. By setting the ticker (e.g., PETR4) as the key, Kafka ensures that all messages for that specific asset are always routed to the same partition. This guarantees that any consumer will process price updates in the exact order they occurred, preventing a race condition where an older price might be processed after a newer one.

Code Highlights:

Rate Limiting: Implemented a time.sleep(0.5) between API calls to respect the limits of the Brapi free tier and avoid throttling.
Data Mapping: The payload is transformed into a standardized format (ticker, price, volume, timestamp) before transmission.

# Snippet of the Kafka production with keys in main.py
producer.produce(
    topic=TOPIC_NAME,
    key=ticker, # Ensures ordering per asset
    value=json.dumps(payload).encode('utf-8'),
    callback=delivery_report
)

✅ Validating the Execution

To ensure the integration is working as expected, I validated two main output points:

MongoDB: I verified the price_history collection in the market_data_db, confirming that documents are being inserted with the correct created_at timestamp.

Kafka: Using the management UI, I confirmed that messages are arriving with the correct keys and values in the trading-assets-market-data-v1 topic.

🚀 Conclusion

With this service running, our simulator now "sees" the market in real time. The next challenge is to consume these events from within the Java microservices to update user portfolios and trigger order matching.

Do you have any questions about the ingestion strategy or using Kafka with Python? Let's discuss in the comments!

🔎 About the series

⬅️ Previous Post: Infrastructure as Code.

📘 Series Index: Series Guide.

Links:

Integrador de Market Data: Consumindo Dados Reais com Python, MongoDB e Kafka

Roberto de Vargas Neto — Sat, 14 Mar 2026 20:08:02 +0000

Olá, pessoal!

Dando continuidade à série My Broker B3, hoje vamos falar sobre o componente que alimenta todo o ecossistema com dados reais do mercado financeiro brasileiro: o Broker Market Data API.

Este microserviço em Python atua como um ingestor, conectando o mundo externo (API Brappi) à nossa infraestrutura interna.

🏗️ A Solução e o Fluxo de Dados

O objetivo aqui é garantir que os preços dos ativos estejam sempre atualizados para os outros serviços. O fluxo foi desenhado em três etapas principais:

Ingestão Agendada: O serviço percorre uma Watchlist de 50 ativos (incluindo Blue Chips como PETR4 e VALE3, além de FIIs e ETFs).
Persistência Histórica (MongoDB): Antes de qualquer processamento, o payload completo é salvo no MongoDB. Isso garante que tenhamos uma trilha de auditoria e dados para análises futuras.
Streaming de Eventos (Kafka): O preço atualizado é publicado no tópico trading-assets-market-data-v1. Isso permite que qualquer outro microserviço reaja a essa mudança em tempo real.

🛠️ Detalhes da Implementação

Escolhi Python 3.12 pela sua agilidade em lidar com requisições HTTP e integração com drivers de dados.

A importância da Chave no Kafka (Message Key)

Uma decisão técnica vital neste serviço foi o uso do ticker do ativo como chave (key) da mensagem enviada ao Kafka.

Por que isso é importante?
O Kafka garante a ordenação das mensagens apenas dentro de uma partição. Ao definir o ticker (ex: PETR4) como chave, o Kafka assegura que todas as mensagens desse ativo caiam sempre na mesma partição. Isso garante que qualquer consumidor lerá os eventos na ordem exata em que ocorreram, evitando que um preço antigo seja processado após um preço mais recente.

Destaques do Código:

Rate Limiting: Como utilizo o plano gratuito da Brapi, o código implementa um time.sleep(0.5) entre as chamadas para respeitar os limites da API e evitar throttling.
Data Mapping: O payload é transformado para um formato padronizado antes de ser enviado para o Kafka, garantindo que os serviços consumidores recebam apenas o necessário (ticker, price, volume e timestamp).

# Trecho do mapeamento de dados no main.py
payload = {
    "ticker": result.get("symbol"),
    "price": result.get("regularMarketPrice"),
    "volume": result.get("regularMarketVolume"),
    "updated_at": result.get("regularMarketTime")
}

✅ Validando a Execução

Para garantir que a integração está funcionando, validei os dois pontos de saída:

MongoDB: Verifiquei a coleção price_history no banco market_data_db, onde os documentos estão sendo inseridos com o campo created_at gerado pelo nosso repositório.

Kafka: Através da interface de gestão, confirmei a chegada das mensagens com as chaves (tickers) e valores corretos no tópico.

🚀 Conclusão

Com este serviço rodando, nosso simulador agora "enxerga" o mercado em tempo real. O próximo desafio é consumir esses eventos de dentro das APIs Java para atualizar as carteiras dos usuários.

Ficou com alguma dúvida sobre a estratégia de ingestão ou sobre o uso do Kafka com Python? Deixe nos comentários!

Para acompanhar essa série clique aqui.

🔎 Sobre a série

⬅️ Post Anterior: Infraestrutura como Código.

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

Links:

Series Roadmap: Building a Stock Brokerage Simulator with Microservices

Roberto de Vargas Neto — Sat, 14 Mar 2026 14:12:01 +0000

Welcome to the official index for the My Broker B3 series. This post serves as a central hub where I organize all the articles about this financial ecosystem's development in the ideal reading order.

This project is a hands-on lab where I apply software engineering, distributed systems, and messaging to simulate the integration between a Brokerage and the Stock Exchange.

🚀 Series Articles

Project Overview
- Introduction to the macro architecture, tech stack (Java, Python, Kafka, RabbitMQ), and the simulator's goals.
Infrastructure with Docker Compose
- How I deployed 12 containers (SQL, NoSQL, Cache, and Messaging) ensuring domain isolation and .env best practices.
Market Data: The Python, MongoDB, and Kafka Integrator
- How I built the ingestion service that consumes the Brappi API, ensures historical persistence in MongoDB, and uses Kafka keys to guarantee message ordering per asset.
Tooling Tips: MongoDB Compass and Offset Explorer
- How to configure and use visual tools to validate MongoDB persistence and Kafka message streams during development.
From Stream to Database: Processing Market Data with Spring Boot, Redis, and Flyway
- The first Java microservice in the ecosystem: how to consume Kafka data, version the database with Flyway, and implement a high-performance Redis cache to serve asset prices.

... more articles will be added as the development progresses!

Connect with me:

Guia da Série: Construindo um Simulador de Corretora com Microserviços

Roberto de Vargas Neto — Sat, 14 Mar 2026 13:59:02 +0000

Seja bem-vindo ao índice oficial da série My Broker B3. Aqui você encontrará todos os artigos publicados sobre o desenvolvimento deste ecossistema financeiro, organizados na ordem ideal de leitura.

Este projeto é um laboratório prático onde aplico engenharia de software, sistemas distribuídos e mensageria para simular a integração entre uma Corretora e a B3.

🚀 Artigos da Série

Visão Geral do Projeto
- Apresentação da arquitetura macro, stack tecnológica (Java, Python, Kafka, RabbitMQ) e os objetivos do simulador.
Infraestrutura com Docker Compose
- Como subi 14 containers (SQL, NoSQL, Cache e Mensageria) garantindo isolamento de domínios e boas práticas com .env.
Market Data: O Integrador Python, MongoDB e Kafka
- Como construí o serviço de ingestão que consome a API Brappi, garante a persistência histórica no MongoDB e utiliza chaves no Kafka para assegurar a ordenação das cotações por ativo.
Dicas de Ferramentas: MongoDB Compass e Offset Explorer
- Como configurar e utilizar ferramentas visuais para validar a persistência no MongoDB e o fluxo de mensagens no Kafka durante o desenvolvimento.
Do Stream para o Banco: Processando Market Data com Spring Boot, Redis e Flyway
- O primeiro microserviço Java do ecossistema: como consumir dados do Kafka, versionar o banco com Flyway e implementar um cache de alta performance com Redis para servir os preços dos ativos.

... mais artigos serão adicionados conforme o desenvolvimento avança!

Minhas Redes:

Infrastructure as Code: Deploying a Financial Ecosystem with Docker Compose

Roberto de Vargas Neto — Sat, 14 Mar 2026 13:51:38 +0000

Hello, everyone! 👋

In my previous post, I presented an overview of My Broker B3. Today, let's "open the hood" and talk about the foundation that supports this entire ecosystem: the infrastructure.

For a microservices system, manually configuring each database, message broker, and monitoring tool would be a productivity nightmare. That’s why I used Docker Compose to create a local environment that replicates the needs of a highly complex distributed system.

🏗️ Domain Isolation Strategy

A central design decision for this project was data isolation by domain. Instead of a single monolithic database, each microservice has its own instance or logical base:

Relational Persistence (SQL): I use MySQL 8.0 for the Brokerage domains (Identity, Wallet, Order, and Asset) and PostgreSQL 15 for the B3 Core. This ensures domain decoupling—for instance, a failure in the order database won't affect the identity service.
Cache Layer (Redis): I implemented isolated, lightweight Redis (Alpine) instances for market data and wallet services, guaranteeing sub-millisecond latency where speed is critical.
NoSQL (MongoDB): A centralized instance for storing unstructured data, such as price history (Ticks) and reports, allowing for high schema flexibility.

📡 Messaging: The System Backbone

The docker-compose.yml file orchestrates two messaging giants for different purposes:

Apache Kafka (KRaft): Configured in the modern KRaft mode (eliminating the need for Zookeeper), which makes the container lightweight and stable for local development. It handles the high volume of internal events.
RabbitMQ: Acts as our communication bridge between the Broker and the B3 simulator, ensuring complete decoupling between the systems.

📊 Observability from "Day 1"

You can't manage what you don't measure. That’s why I included Prometheus and Grafana directly into the core infrastructure. As soon as a microservice is deployed, it can immediately export metrics to be viewed in real-time dashboards.

🔐 Security and Configuration with .env

A crucial detail for any professional project is secrets management and configuration. In my docker-compose.yml, I used environment variables to avoid hardcoding passwords and ports.

All sensitive configurations are isolated in a .env file (ignored by Git), while an .env.example file is provided as a template. This demonstrates a security best practice by ensuring that credentials are never exposed in the source code.

# Excerpt from docker-compose using environment variables.
broker-identity-db:
  image: mysql:8.0
  environment:
    MYSQL_DATABASE: ${BROKER_IDENTITY_DB_NAME}
    MYSQL_USER: ${BROKER_DB_USER}
    MYSQL_PASSWORD: ${BROKER_DB_PASS}

🚀 How to Run

With the infrastructure automated, a single command is enough to spin up all 14 containers:

docker-compose up -d

This standardization ensures that the development environment is identical for anyone collaborating on the project, eliminating the classic "it works on my machine" problem.

In the next post, we’ll talk about the first microservice I created. This service integrates with the external Brappi API, stores data in MongoDB, and publishes real-time price updates to a Kafka topic.

🔎 About the series

⬅️ Previous Post: Building a Microservices Ecosystem.

📘 Series Index: Series Guide.

Links:

Infraestrutura como Código: Subindo o ecossistema financeiro com Docker Compose

Roberto de Vargas Neto — Sat, 14 Mar 2026 12:58:28 +0000

Olá, pessoal!

No post anterior, apresentei a visão geral do My Broker B3. Hoje, vamos "abrir o capô" e falar sobre a fundação que sustenta todo esse ecossistema: a infraestrutura.

Para um sistema de microserviços, configurar manualmente cada banco de dados, broker de mensagens e ferramenta de monitoramento seria um pesadelo de produtividade. Por isso, utilizei o Docker Compose para criar um ambiente local que replica fielmente as necessidades de um sistema distribuído de alta complexidade.

🏗️ A Estratégia de Isolamento de Domínios

Uma decisão central no design deste projeto foi o isolamento de dados por domínio. Em vez de um único banco de dados monolítico, cada microserviço possui sua própria instância ou base lógica:

Persistência Relacional (SQL): Utilizo MySQL 8.0 para os domínios da Corretora (Identity, Wallet, Order e Asset) e PostgreSQL 15 para o núcleo da B3. Isso garante que uma falha no banco de ordens não afete o serviço de identidade, por exemplo.
Camada de Cache (Redis): Implementei instâncias leves de Redis (Alpine) isoladas para dados de mercado e carteira, garantindo latência sub-milissegundo onde a velocidade é crítica.
NoSQL (MongoDB): Uma instância centralizada para armazenar dados não estruturados, como históricos de preços (Ticks) e relatórios.

📡 Mensageria: O Backbone do Sistema

O arquivo docker-compose.yml orquestra dois gigantes da mensageria para diferentes propósitos:

Apache Kafka (KRaft): Configurado no modo moderno KRaft (sem Zookeeper), o que torna o container mais leve e estável para o desenvolvimento local. Ele lida com o alto volume de eventos internos.
RabbitMQ: Atua como a nossa ponte (Bridge) de comunicação entre o Broker e a B3, garantindo o desacoplamento total entre os sistemas.

📊 Observabilidade desde o "Dia 1"

Não se gerencia o que não se mede. Por isso, incluí Prometheus e Grafana diretamente na infraestrutura base. Assim que um microserviço sobe, ele já pode exportar métricas que são visualizadas em dashboards em tempo real.

🔐 Segurança e Configuração com .env

Um detalhe crucial para qualquer projeto profissional é a gestão de segredos e configurações. No docker-compose.yml, utilizei variáveis de ambiente para evitar o hardcoding de senhas e portas.

Toda a configuração sensível fica isolada em um arquivo .env (ignorado pelo Git), enquanto um arquivo .env.example é fornecido como template. Isso demonstra uma boa prática de segurança:

# Trecho do docker-compose utilizando variáveis de ambiente
broker-identity-db:
  image: mysql:8.0
  environment:
    MYSQL_DATABASE: ${BROKER_IDENTITY_DB_NAME}
    MYSQL_USER: ${BROKER_DB_USER}
    MYSQL_PASSWORD: ${BROKER_DB_PASS}

🚀 Como Executar

Com a infraestrutura automatizada, basta um comando para subir os 12 containers:

docker-compose up -d

Essa padronização garante que o ambiente de desenvolvimento seja idêntico para qualquer pessoa que colaboresse no projeto se fosse o caso, eliminando o clássico problema do "na minha máquina funciona".

No próximo post, vamos falar sobre o primeiro microserviço que criei que faz a integração com API externa da Brappi, armazena em um banco mongo e publica em um tópico Kafka os preços atualizados!

🔎 Sobre a série

⬅️ Post Anterior: Construindo um ecossistema de Microserviços.

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

Links:

Building a Microservices Ecosystem: Stock Brokerage Simulator (My Broker B3)

Roberto de Vargas Neto — Sat, 14 Mar 2026 01:46:15 +0000

Hello, everyone!

I’m starting a series of articles to document the development of My Broker B3. This is a personal project where I’m applying advanced software engineering concepts, distributed systems, and messaging to simulate the real-world operations of a stock brokerage.

The main objective is to create an ecosystem that handles challenges such as data consistency, low latency, and asynchronous communication, all while integrating a simplified matching engine.

🏗️ System Architecture

The project was designed following a microservices approach, using a hybrid stack to leverage the best of each ecosystem:

Core Backend (Java/Spring Boot 3): Responsible for the order (broker-order-api), wallet (broker-wallet-api), and asset management (broker-asset-api) APIs.
Market Data (Python): An integrator (broker-market-data-api) that manages market data ingestion via scheduled tasks.
Matching Engine (Java): A B3 simulator (b3-matching-engine-api) that processes the execution of orders sent by the brokerage.

⚙️ Data Flow and Technologies

To ensure resilience and scalability, I adopted a hybrid communication strategy:

Synchronous (REST): Used for critical real-time validations, such as verifying the wallet balance before allowing an order to be sent.
Asynchronous (Event-Driven):
- Apache Kafka: Acts as an internal event bus for distributing market quotes and asset-related events.
- RabbitMQ: Manages the communication between the Broker and the B3 Simulator through dedicated queues.

Persistence and Caching

Each service utilizes the data strategy that best suits its specific purpose:

Technology	Use Case
MySQL / PostgreSQL	Transactional data, orders, and wallet history.
MongoDB	Market quotes history (Time-series data) within the Market Data API.
Redis	"Hot" cache for market prices to ensure ultra-high-speed queries.

Technical draw

🚀 What’s Next?

This post is just the kickoff. In the upcoming articles, I plan to detail:

Infrastructure: How to deploy all these resources on AWS (Free Tier).
Messaging: A deep dive into Kafka and RabbitMQ configurations.
Technical Challenges: How I’m handling eventual consistency and the matching engine's processing logic.

Feel free to leave your feedback or questions in the comments!

🔎 About the series

📘 Series Index: Series Guide.

Links:

Construindo um Ecossistema de Microserviços: Simulador de Corretora de Valores (My Broker B3)

Roberto de Vargas Neto — Sat, 14 Mar 2026 00:46:37 +0000

Olá, pessoal!

Estou iniciando uma série de artigos para documentar o desenvolvimento do My Broker B3. Este é um projeto pessoal onde estou aplicando conceitos avançados de engenharia de software, sistemas distribuídos e mensageria para simular o funcionamento real de uma corretora de valores.

O objetivo principal é criar um ecossistema que lide com desafios de consistência de dados, baixa latência e comunicação assíncrona, integrando um motor de negociação (Matching Engine) simplificado.

🏗️ A Arquitetura do Sistema

O projeto foi desenhado seguindo a filosofia de microserviços, utilizando uma stack híbrida para aproveitar o melhor de cada ecossistema:

Core Backend (Java/Spring Boot 3): Responsável pelas APIs de ordens (broker-order-api), carteira (broker-wallet-api) e gestão de ativos (broker-asset-api).
Market Data (Python): Um integrador (broker-market-data-api) que gerencia a ingestão de dados de mercado via agendamento.
Matching Engine (Java): Um simulador da B3 (b3-matching-engine-api) que processa a execução das ordens enviadas pela corretora.

⚙️ Fluxo de Dados e Tecnologias

Para garantir resiliência e escalabilidade, adotei uma estratégia de comunicação híbrida:

Síncrona (REST): Utilizada para validações críticas em tempo real, como verificar o saldo da carteira antes de permitir o envio de uma ordem.
Assíncrona (Event-Driven):
- Apache Kafka: Atua como barramento de eventos interno para distribuição de cotações e eventos de ativos.
- RabbitMQ: Gerencia a comunicação entre a Corretora e o Simulador da B3 através de filas dedicadas.

Persistência e Cache

Cada serviço utiliza a estratégia de dados que melhor se adapta à sua função:

Tecnologia	Caso de Uso
MySQL / PostgreSQL	Dados transacionais, ordens e histórico de carteira.
MongoDB	Histórico de cotações (Time-series data) na API de Market Data.
Redis	Cache "quente" de preços de mercado para consultas de altíssima velocidade.

Desenho técnico

🚀 O que vem por aí?

Este post é apenas o "pontapé inicial". Nos próximos artigos, pretendo detalhar:

Infraestrutura: Como subir todos esses recursos na AWS (Free Tier).
Mensageria: Deep dive na configuração do Kafka e RabbitMQ.
Desafios Técnicos: Como lidar com a consistência eventual e o processamento do motor de matching.

Fiquem à vontade para deixar feedbacks ou dúvidas nos comentários!

🔎 Sobre a série

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

Links:

DEV Community: Roberto de Vargas Neto

From Stream to Database: Processing Market Data with Spring Boot, Redis, and Flyway

🎯 MVP Focus (Minimum Viable Product)

🏗️ The Pillars of the Asset API

1. Database Evolution with Flyway

2. Kafka Consumer: Real-Time Reactivity

3. Service Layer: Hybrid Persistence (SQL + Redis)

4. Controller: Serving the Information

🛠️ What’s Next?

🔎 About the series

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

🎯 Foco no MVP (Minimum Viable Product)

🏗️ Os Pilares da Asset API

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

2. Consumidor Kafka: Reatividade em Tempo Real

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

4. Controller: Disponibilizando a Informação

🛠️ O que vem a seguir?

​🔎​ Sobre a série

Tooling Tips: Visualizing Your Data in MongoDB and Kafka

1. MongoDB Compass: The Official MongoDB GUI

📸 Viewing in document mode:

📸 Table view:

2. Offset Explorer (Formerly Kafka Tool)

📸 Visualizando as mensagens

💡 Why is this important?

🚀 Conclusion

🔎 About the series

Dica de Ferramentas: Como Visualizar seus Dados no MongoDB e Kafka

1. MongoDB Compass: O GUI Oficial do MongoDB

📸 Visualização em modo documento:

📸 Visualização em modo tabela:

2. Offset Explorer (Antigo Kafka Tool)

📸 Visualizando as mensagens

💡 Por que isso é importante?

🚀 Conclusão

​🔎​ Sobre a série

Market Data Integrator: Consuming Real-Time Data with Python, MongoDB, and Kafka

🏗️ The Solution and Data Flow

🛠️ Implementation Details

The Importance of the Kafka Message Key

Code Highlights:

✅ Validating the Execution

🚀 Conclusion

🔎 About the series

Integrador de Market Data: Consumindo Dados Reais com Python, MongoDB e Kafka

🏗️ A Solução e o Fluxo de Dados

🛠️ Detalhes da Implementação

A importância da Chave no Kafka (Message Key)

Destaques do Código:

✅ Validando a Execução

🚀 Conclusão

​🔎​ Sobre a série

Series Roadmap: Building a Stock Brokerage Simulator with Microservices

🚀 Series Articles

Guia da Série: Construindo um Simulador de Corretora com Microserviços

🚀 Artigos da Série

Infrastructure as Code: Deploying a Financial Ecosystem with Docker Compose

🏗️ Domain Isolation Strategy

📡 Messaging: The System Backbone

📊 Observability from "Day 1"

🔐 Security and Configuration with .env

🚀 How to Run

🔎 About the series

Infraestrutura como Código: Subindo o ecossistema financeiro com Docker Compose

🏗️ A Estratégia de Isolamento de Domínios

📡 Mensageria: O Backbone do Sistema

📊 Observabilidade desde o "Dia 1"

🔐 Segurança e Configuração com .env

🚀 Como Executar

​🔎​ Sobre a série

Building a Microservices Ecosystem: Stock Brokerage Simulator (My Broker B3)

🏗️ System Architecture

⚙️ Data Flow and Technologies

Persistence and Caching

Technical draw

🚀 What’s Next?

🔎 About the series

Construindo um Ecossistema de Microserviços: Simulador de Corretora de Valores (My Broker B3)

🏗️ A Arquitetura do Sistema

🔎 Sobre a série

🔎 Sobre a série

🔎 Sobre a série

🔎 Sobre a série

🔎 Sobre a série