Olá, pessoal!

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

O objetivo não é ter um sistema de produção, mas sim uma POC (Proof of Concept) que valide o processamento de ordens em tempo real, gestão de custódia financeira e orquestração de market data usando arquitetura orientada a eventos.

🏗️ A Visão Geral do Ecossistema

O projeto foi desenhado seguindo a filosofia de microserviços com uma stack híbrida — cada serviço usa a tecnologia que melhor se adapta à sua função:

                    [broker-gateway-api]
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
   [broker-order-api] [broker-wallet] [broker-asset]
          │                │
     RabbitMQ           Kafka (order-events-v1)
          │
   [b3-matching-engine]
          │
       Redis ◀── [b3-market-sync-api] ◀── [brapi.dev]

Os Serviços

Lado da Corretora (Broker)

Lado da B3 (Simulador)

⚙️ Estratégia de Comunicação

Uma das decisões mais importantes do projeto foi escolher quando usar comunicação síncrona e quando usar assíncrona. A regra foi simples: se a resposta é necessária agora para continuar o fluxo, use REST. Se pode aguardar, use mensageria.

Síncrona (REST/Feign)

• broker-order-api → broker-asset-api: valida se o ticker existe antes de criar a ordem
• broker-order-api → broker-wallet-api: valida saldo antes de processar compra
• broker-identity-api → broker-wallet-api: cria conta na wallet no registro

Assíncrona (RabbitMQ)

• broker-order-api → b3-matching-engine-api: envio de ordens para execução
• b3-matching-engine-api → broker-order-api: feedback do resultado (FILLED/REJECTED)

Assíncrona (Kafka)

• broker-market-data-api → tópico assets-market-data-v1 → broker-asset-api
• broker-order-api → tópico order-events-v1 → broker-wallet-api

💾 Estratégia de Persistência

Cada serviço usa o banco que melhor se adapta à sua natureza:

🔄 O Fluxo de uma Ordem — Ponta a Ponta

Para materializar a arquitetura, veja o que acontece quando um usuário envia uma ordem de compra:

1. POST /api/v1/orders
        │
        ├─ Valida saldo → broker-wallet-api (REST)
        ├─ Persiste PENDING → MySQL
        ├─ Publica PENDING → Kafka (broker-wallet bloqueia saldo)
        └─ Envia para B3 → RabbitMQ

2. B3 processa, consulta preço no Redis
        │
        ├─ FILLED/REJECTED → RabbitMQ → broker-order-api
        ├─ Atualiza status → MySQL
        └─ Publica status final → Kafka (broker-wallet liquida/estorna)

Do clique do usuário até o saldo atualizado na carteira, passando por validação, matching de preço e consistência eventual.

🚀 O que você vai encontrar na série

Cada post documenta a construção de um serviço, com foco nas decisões técnicas, os problemas encontrados e como foram resolvidos:

1. Visão Geral ← você está aqui
2. Infraestrutura — Docker Compose com 12+ containers
3. broker-market-data-api — Python, Brapi, MongoDB, Kafka
4. b3-market-sync-api — Sincronização de preços para o Redis
5. b3-matching-engine-api — O motor de execução da B3
6. broker-asset-api — Catálogo de ativos e cache
7. broker-wallet-api — Custódia financeira
8. broker-order-api — O maestro das ordens
9. broker-identity-api — Autenticação e JWT
10. broker-gateway-api — API Gateway

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

🔎 Sobre a série

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

Links:

• LinkedIn
• GitHub