Midaz is built for scalability, enabling banks to expand to millions of accounts and transactions. However, the way you set up and utilize Midaz significantly affects performance and efficiency. By thoughtfully structuring your deployment—utilizing ledgers, segmenting workloads, and implementing microservices—you can effectively handle extensive banking operations.

Structuring Entities for High Transaction Volumes

Partitioning by Organizations, Ledgers, and Accounts

If your bank processes millions of transactions daily, consider distributing workloads across multiple accounts, ledgers, or even organizations. For example, you could segment customers by last name initials or allocate separate ledgers per region.

Each ledger in Midaz functions as an independent book—transactions within a ledger are processed together. Distributing load this way prevents a single ledger from becoming a bottleneck. Midaz's architecture supports scaling out, allowing different ledgers to operate on separate instances or database partitions.

Lock-Oriented Operations

Concurrent transactions are locked at the account level within each ledger or organization. This ensures orderly transaction processing using a FIFO (first in, first out) approach, preventing race conditions on the same account.

The @external account operates without locks, meaning concurrent transactions can occur freely but are still subject to atomicity rules.

Horizontal Scaling of Services

Midaz is built on a microservices architecture, meaning different components—such as transaction processing and querying—can be scaled independently. Start small, but as demand increases, scale specific services accordingly.

For high loads, deploy multiple instances of the transaction processing service behind a load balancer and leverage Kubernetes (K8s) pod scaling.

CQRS and Read Replicas

Midaz employs CQRS (Command Query Responsibility Segregation) to separate write and read operations, allowing each to be optimized individually.

Use this advantageously: heavy reporting and query loads should go to read replicas, keeping transaction commits lean and efficient. Reads do not slow down writes, and vice versa, ensuring high throughput.

Batching and N:N Transactions

Where possible, batch multiple related operations into a single transaction to reduce processing overhead. Use N:N transactions for bulk operations such as mass payouts.

For instance, handling 100 debits and 100 credits in one batch is often more efficient than processing 100 individual transactions—provided they belong to the same logical operation set. Midaz is designed to handle such complex transactions at scale.

Monitoring and Iterative Scaling

Monitor key metrics: transaction latency, throughput, resource usage (CPU/memory), and database performance. Use Midaz’s built-in observability tools (OpenTelemetry + Grafana) or integrate with your infrastructure monitoring.

Scale out (or up) proactively when approaching performance thresholds. Since Midaz is modular and open-source, you have the flexibility to distribute deployment as needed.

Handling Multi-Currency and Multi-Entity Operations

Multi-Currency Strategies

Midaz supports multi-currency transactions by maintaining separate asset accounts per currency. To optimize scaling:

• Ensure all required currency assets are configured.
• Account for currency-specific logic (e.g., rounding, conversion rates) in your integration layer.
• If currency conversion is frequent (e.g., forex trading), manage it in a separate module or service—potentially using our Exchange Engine plugin. Midaz will handle debits/credits, but an external FX rate service may be necessary.
• Separate ledgers per currency are generally unnecessary unless policy dictates. Instead, use the chart-of-accounts to categorize accounts by currency for reporting clarity.
• If one currency (e.g., local currency) dominates transactions, keep all currencies in a single ledger unless cross-currency operations become a complexity.

Multiple Entities: Consolidation and Separation

For banks operating across multiple countries or legal entities:

• Use the organization hierarchy to segment entities, with each having its own base currency, local assets, and ledgers.
• Inter-entity transactions are treated as external movements—one organization credits its external account while another debits its own.
• Running multiple organizations on the same Midaz instance is feasible, but ensure sufficient resources are allocated. Microservices process all requests collectively, so overall volume matters.
• Deploying separate Midaz instances for isolated entities is possible, but it limits unified visibility. Typically, a single Midaz cluster with internal organization separation is more practical.

Performance Optimization Best Practices

Indexing and Queries

Use Midaz APIs for data retrieval instead of direct database queries. The APIs are designed for efficiency with built-in indexing, enabling operations such as retrieving all transactions for an account or listing all accounts in a portfolio.

Testing at Scale

Before full deployment, simulate high traffic using load testing tools. Create millions of accounts, run heavy transaction volumes, and monitor performance.

Midaz's architecture (microservices, CQRS) is built for high-scale operations, but real-world testing helps fine-tune your implementation. Look for linear scalability—scaling app servers should proportionally increase throughput.