Architecture & Core components
Context
Midaz is built on a robust and scalable architecture that employs modern design principles to ensure flexibility, reliability, and performance. The system is composed of several core components, each designed to handle specific functionalities within the financial ledger and transaction management domain.
Domain-Driven Design (DDD) Approach and Bounded Contexts
Midaz utilizes Domain-Driven Design to clearly define the system structure and functionality around the core domain of financial transactions. This approach helps in managing complexities by dividing the system into different bounded contexts, each representing a specific sub-domain.
Bounded Contexts Include:
Authentication and Authorization: Manages user identity and access controls.
Onboarding: Handles the registration and setup of new users and organizations, including the creation and management of Ledgers.
Portfolio: Deals with the management of financial products, accounts, and portfolios, and also handles the management of financial instruments.
Transaction: Responsible for managing transaction templates, the chart of accounts, individual transactions, and their operations.
Important Observation: It is important to note that all domains are covered by the Authentication and Authorization mechanisms, ensuring secure and controlled access across the entire system.
Architecture - Overview
Modular Design: Enables easy maintenance and scalability.
Microservices Architecture: Each component operates independently but communicates effectively through well-defined interfaces.
CQRS (Command Query Responsibility Segregation): This approach separates read and write operations, enhancing performance and scalability by allowing each to be optimized independently. Midaz uses well-defined ports for system interactions, coupled with adapters that manage external and internal service integrations. This makes the platform highly adaptable and extensible.
Little More About Command Query Responsibility Segregation
CQRS (Command Query Responsibility Segregation) is a design pattern that separates the responsibilities of handling commands (requests to modify data) from handling queries (requests to retrieve data). This separation allows for optimized and specialized handling of each type of operation, resulting in better scalability, maintainability, and clarity of design.
Commands vs. Queries
Commands are operations that change the state of the system. For example, creating a new user or updating an order.
Queries are operations that read the state of the system without modifying it. For example, retrieving a list of users or viewing order details.
By separating these two types of operations, the system can be optimized independently for reading and writing.
Why does Midaz use CQRS
CQRS provides Midaz with the scalability, separation of concerns, optimized data storage, flexibility, and event-driven capabilities needed to handle thousands of transactions efficiently. By leveraging CQRS, Midaz ensures that it can meet the demanding requirements of a ledger system while maintaining clarity and maintainability.
Primaries Ports
Serve as interfaces for incoming requests to interact with the application's domain logic (Apps CQRS - Command & Query Handler).
APPs CQRS (Command & Query Handler)
The domain encompasses the core business rules, logic, and data.
This includes operations, calculations, validations, and decisions that are central to the business or application.
Secondaries Ports (Interfaces)
Midaz interfaces with various external systems to enhance functionality and extend capabilities.
These integrations include:
Financial Institutions: Interfaces for real-time transaction processing.
Event-Driven: In an event-driven architecture, adapters are crucial for facilitating communication between the application's core logic and external systems or services.
Other Integrations
Outbound Adapters
Manage outgoing communications to external systems, handling data transfer and external API interactions.
Core Components - Overview
Midaz uses PostgreSQL and MongoDB to handle different types of data across its service domains effectively. PostgreSQL is chosen for its reliability and robust transactional support, which are crucial for the structured data associated with financial transactions and API interactions. It ensures data integrity and supports complex query operations that are essential for the transaction and portfolio management components of Midaz.
On the other hand, MongoDB is utilized for its flexibility in handling unstructured and semi-structured data. This is particularly beneficial for managing metadata, which can vary greatly and evolve with the system. MongoDB's dynamic schema allows for quick adjustments and scaling, making it ideal for areas of the system that require rapid development and frequent updates.
Together, these databases provide a comprehensive solution that balances strict data integrity requirements with flexibility and scalability, supporting Midaz's diverse data management needs efficiently.
Why PostgreSQL?
ACID Compliance: PostgreSQL ensures the integrity of data with its strong ACID (Atomicity, Consistency, Isolation, Durability) compliance. This is crucial for financial applications where the accuracy and reliability of transaction data are paramount.
Advanced SQL Capabilities: It supports a rich set of SQL functionalities, which is ideal for complex queries involving multiple tables and advanced data manipulation. This makes it suitable for handling the structured data of API endpoints.
Performance and Scalability: PostgreSQL is known for its ability to handle high volumes of transactions and data without sacrificing performance, essential for the transaction-heavy operations in financial systems.
Security Features: It offers robust security features, including strong access controls and support for SSL to secure data transmissions, which are critical in managing sensitive financial data.
Why MongoDB?
Schema Flexibility: MongoDB stores data in BSON (binary JSON) format, which allows for a flexible and dynamic schema. This is particularly useful for metadata which can vary greatly and evolve over time without needing predefined schemas.
Scalability: It excels in horizontal scalability, thanks to its sharding capabilities. This makes it ideal for managing large volumes of unstructured data that can grow dynamically.
High Performance for Unstructured Data: MongoDB can efficiently store and retrieve unstructured or semi-structured data, which is often the case with metadata in systems like Midaz.
Rich Query Language: While primarily a NoSQL database, MongoDB supports complex query operations and an aggregation framework that can perform data processing and analysis directly in the database.
Why Redis?
Speed: Redis is an in-memory data store, which means it uses RAM for data storage. This results in exceptionally fast read and write operations, making it ideal for situations where speed is critical, such as caching, session management, or real-time applications.
Data Structures: Unlike many other key-value stores, Redis supports a variety of data structures such as strings, lists, sets, hashes, sorted sets, and more. This versatility allows developers to use Redis for a wide range of problems, from simple caching to complex functional programming tasks.
Persistence Options: While Redis is primarily an in-memory database, it offers options to persist data to disk. This means it can recover its state after a restart, combining the performance of in-memory processing with the reliability of disk storage.
Scalability: Redis supports master-slave replication, allowing data to be mirrored across multiple Redis servers. This replication capability not only helps in data redundancy but also in scaling read operations across multiple servers.
Below you will find the list of domains and the components used in each.
Components
Below you will find the list of domains and the components used in each.
Authentication and Authorization:
PostgreSQL for API data storage
Onboarding:
PostgreSQL for API data storage
MongoDB for metadata storage
Redis for cache storage
Portfolio:
PostgreSQL for API data storage
MongoDB for metadata storage
Redis for cache storage
Transaction:
PostgreSQL for API data storage
MongoDB for metadata storage
Redis for cache storage
This is the best combination for Midaz
The strategic use PostgreSQL, MongoDB and Redis allows Midaz to leverage the specific strengths of each database system, optimizing the handling of structured API data with PostgreSQL while benefiting from the flexibility, scalability of MongoDB for metadata management and Redis to improve performance. This dual-database approach is often seen in systems that require robust data integrity for core operations alongside the need to manage more flexible, evolving datasets.
Last updated
