Skip to main content
Midaz is designed for genuine portability and independence. You can deploy it on any public or private cloud without being tied to a single provider. Underneath, we utilize a microservices architecture, which allows each component to be self-sufficient and easily scalable (or replaceable) as your requirements change.

​
Microservices architecture

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

​
1. Cluster layer (customer management)

This layer is managed by the customer and provides the Kubernetes foundation for running Midaz. We recommend enabling the following services to ensure 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, etc.).
Important transition: Starting with newer releases, Midaz no longer includes a bundled console in its repository. The visual interface is now provided by Lerian Console, a unified platform that includes Midaz as one of its product modules.If you’re using an older version of Midaz, you may still have access to the standalone Midaz Console. However, this component is now in maintenance mode and will only receive critical security patches. We recommend migrating to Lerian Console to access the latest features and improvements.

​
3. Back-end layer

The back-end is implemented as a modular monolith, exposed as a single service called Ledger, which concentrates the core responsibilities of the Midaz Ledger. Within this structure, the logic is organized by domains, primarily:
  • Onboarding domain: Responsible for organization, ledger, asset, portfolio, segment, and account setup.
  • Transactions domain: Handles financial transactions, operations, and asset movements.
This approach preserves clear domain boundaries while simplifying deployment and operational complexity.

​
4. Data layer

This layer includes the databases and infrastructure components required to support application data and event flows:
  • PostgreSQL (named “Midaz”): Used as the leading relational database; includes a replica for redundancy or read scaling.
  • Valkey: A Redis-compatible key-value store for caching or fast data retrieval.
  • MongoDB: Likely used for storing unstructured or semi-structured data.
  • RabbitMQ: Message broker for asynchronous communication between services.
Each of these has associated persistent storage for data durability.

​
5. Helm Chart layer

Midaz uses Helm Charts (specifically lerianstudio/helm) to make infrastructure deployment and configuration more straightforward and efficient. It serves as the connecting element between code and Kubernetes, ensuring each component is deployed consistently across different environments.
For more details, refet to the Deploying using Helm page.

​
Infrastructure that works

In Midaz’s Architecture, each layer is focused, with no unnecessary complexity. It scales naturally and adapts as your needs change. This setup isn’t just technically solid; it’s built for real-world use.
  • Kubernetes coordinates how each layer communicates, ensuring secure and reliable interactions across the system.
  • Helm keeps deployments and configurations in sync, so scaling and updates happen without friction.
Because the platform is modular, extending it is simple. You can add new components as needed without disrupting what’s already in place.