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

Question

Hey folks!

I'm starting a series of articles to document the development of My Broker B3 — a personal project where I apply advanced software engineering concepts, distributed systems and messaging to simulate the real-world operation of a stock brokerage integrated with B3 (the Brazilian stock exchange).

The goal isn't to build a production system, but rather a POC (Proof of Concept) that validates real-time order processing, financial custody management and market data orchestration using an event-driven architecture.

---

️ The Ecosystem Overview

The project was designed following the microservices philosophy with a hybrid stack — each service uses the technology that best fits its function:

                    [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]

The Services

Broker Side

Service	Language	Responsibility
broker-identity-api	Java	Authentication, JWT, user management
broker-gateway-api	Java	API Gateway, routing, JWT validation
broker-order-api	Java	Order lifecycle orchestration
broker-wallet-api	Java	Financial custody, balance and positions
broker-asset-api	Java	Asset catalog and internal market data
broker-market-data-api	Python	Quote ingestion from Brapi → MongoDB + Kafka
broker-report-api	Java	Reports and history

B3 Side (Simulator)

Service	Language	Responsibility
b3-matching-engine-api	Java	Order execution, price matching
b3-market-sync-api	Java	Price synchronization to Redis

---

⚙️ Communication Strategy

One of the most important decisions in the project was choosing when to use synchronous communication and when to use asynchronous. The rule was simple: if the response is needed now to continue the flow, use REST. If it can wait, use messaging.

Synchronous (REST/Feign)

• broker-order-api → broker-asset-api: validates ticker before creating order
• broker-order-api → broker-wallet-api: validates balance before processing buy
• broker-identity-api → broker-wallet-api: creates wallet account on registration

Asynchronous (RabbitMQ)

• broker-order-api → b3-matching-engine-api: sends orders for execution
• b3-matching-engine-api → broker-order-api: execution feedback (FILLED/REJECTED)

Asynchronous (Kafka)

• broker-market-data-api → topic assets-market-data-v1 → broker-asset-api
• broker-order-api → topic order-events-v1 → broker-wallet-api

---

Persistence Strategy

Each service uses the database that best fits its nature:

Technology	Service(s)	Why
MySQL	identity, wallet, order, asset	Transactional data with strong consistency
PostgreSQL	b3-matching-engine	B3 core with execution history
MongoDB	broker-market-data	Quote history — flexible schema
Redis	broker-asset, b3-matching-engine	Real-time price cache for fast decisions

---

The Order Flow — End to End

To materialize the architecture, here's what happens when a user places a buy order:

1. POST /api/v1/orders
        │
        ├─ Validate balance → broker-wallet-api (REST)
        ├─ Persist PENDING → MySQL
        ├─ Publish PENDING → Kafka (broker-wallet blocks balance)
        └─ Send to B3 → RabbitMQ

2. B3 processes, looks up price in Redis
        │
        ├─ FILLED/REJECTED → RabbitMQ → broker-order-api
        ├─ Update status → MySQL
        └─ Publish final status → Kafka (broker-wallet settles/refunds)

From the user's click to the updated wallet balance, through validation, price matching and eventual consistency.

---

What You'll Find in the Series

Each post documents the construction of a service, focusing on technical decisions, problems encountered and how they were solved:

1. Overview ← you are here
2. Infrastructure — Docker Compose with 12+ containers
3. broker-market-data-api — Python, Brapi, MongoDB, Kafka
4. b3-market-sync-api — Price synchronization to Redis
5. b3-matching-engine-api — The B3 execution engine
6. broker-asset-api — Asset catalog and cache
7. broker-wallet-api — Financial custody
8. broker-order-api — The order conductor
9. broker-identity-api — Authentication and JWT
10. broker-gateway-api — API Gateway

Feel free to leave feedback or questions in the comments!

---

About the Series

Series Index: Series Roadmap

---

Links:

• LinkedIn
• GitHub