Skip to main content
In a nutshell: Midaz runs the modular Ledger service and a separate Tracer service. Deploy and scale each service and its supporting infrastructure for your environment. For a business-oriented overview, see About Midaz.
Midaz can run in public or private cloud environments. Select and operate the infrastructure that fits your deployment requirements. Under the hood, Midaz uses a modular architecture. Ledger is organized around domain boundaries, with supporting infrastructure for storage, caching, messaging, and streaming; Tracer runs as a separate service.

​
Modular architecture

The diagram below (Figure 1) shows how the pieces fit together.

Figure 1. Midaz macro-architecture

​
1. Cluster layer (customer management)

The customer manages this layer. It provides the Kubernetes foundation that runs Midaz. Enable these services for a smooth and secure deployment:
  • Service: Networking abstraction to expose and route services.
  • AutoScaler: Automatically adjusts the number of pods.
  • HPA (Horizontal Pod Autoscaler): Scales applications based on metrics.
  • Secrets: Secure management of sensitive data.
  • ConfigMap: Externalized configuration management.
This layer governs and coordinates all components within the cluster.

​
2. Front-end layer

The front-end layer provides the user interface for system interaction (admin panel, dashboards, and more).
Important transition: newer releases of Midaz no longer include a bundled console in the repository. Lerian Console now provides the visual interface. It is a unified platform that includes Midaz as one product module.If you use an older version of Midaz, you may still have the standalone Midaz Console. This component is now in maintenance mode. It receives critical security patches only. Migrate to Lerian Console for the latest features and improvements.

​
3. Back-end layer

The Ledger back-end is a modular monolith that holds the core responsibilities of the Midaz ledger. Midaz also runs Tracer as a separate service. Ledger brings together four core components:
  • Onboarding domain: manages organizations, ledgers, assets, portfolios, segments, and accounts.
  • Transactions domain: handles financial transactions, operations, and asset movements.
  • CRM: is embedded in the Ledger process.
  • Fees: is embedded in the Ledger process.
This approach keeps clear domain boundaries. It also simplifies deployment and lowers operational complexity.

​
4. Data layer

This layer holds the databases and infrastructure components that support application data and event flows:
  • PostgreSQL: separate onboarding and transaction databases, each configured with primary and replica connections.
  • Valkey: A Redis-compatible key-value store for caching or fast data retrieval.
  • MongoDB: Stores unstructured and semi-structured data, such as entity metadata.
  • RabbitMQ: Message broker for asynchronous communication between services.
  • Redpanda: Kafka-compatible broker for Ledger event streams. Ledger publishes configured events to it only when STREAMING_ENABLED=true and streaming brokers are configured.
Persistence is deployment-specific. The bundled Compose configuration does not mount a data volume for Redpanda; configure production storage and retention for each service.

​
5. Helm Chart layer

Midaz uses Helm Charts (specifically lerianstudio/helm) to deploy and configure the infrastructure. The chart connects the code to Kubernetes. It deploys each component the same way across environments.
For more details, see the Deploying using Helm page.

​
How the layers work together

Each layer has a focused role, with no unnecessary complexity. The system scales and adapts as your needs change.
  • Kubernetes coordinates how the layers communicate, for secure and reliable interactions across the system.
  • Helm keeps deployments and configurations in sync, so scaling and updates stay straightforward.
Because the platform is modular, extending it is simple. You can add new components as needed without disruption to what already runs.