Infrastructure as Code: Deploying a Financial Ecosystem with Docker Compose

#mybrokerb3 #docker #infrastructure #containers

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.