Introduction

In the modern world, financial and payment systems process millions of transactions every second, which are related to the movement of user funds. The growing popularity of digital services and the transition of companies to cloud solutions increases the requirements for the secure storage of balance information. Violation of the integrity or security of financial data can lead not only to loss of funds, but also to loss of user confidence in the system. This makes the issue of secure data storage critically important at all stages of system construction.

This paper discusses methods and approaches for building a system for the purpose of securely storing user funds. The key principles of balance sheet data protection are described, and special attention is paid to the balance between security and performance.

The purpose of the research is to develop and describe solutions that ensure the security of user funds while maintaining a high processing speed of incoming transactions.

The scientific novelty of the research lies in the development of an architectural approach to safely work with user funds in financial systems.

Main part

The first step in building a system is to select a suitable database. Since operations with balances require strict consistency and reliable transaction processing, the best choice is to use a relational database, such as PostgreSQL or MySQL [1,2]. Relational databases provide transaction support and ACID compliance, which eliminates data loss, repeated write-offs, or consistency violations while processing a large number of operations. This is critically important for financial systems, as all account transactions must occur atomically, sequentially, and with the ability to roll back changes.

The transaction mechanism of relational systems allows you to reliably process parallel requests using locks and isolation levels. Built-in transaction logs and point recovery mechanisms can be used for incident analysis and subsequent data recovery, which increases resilience to failures.

Using non-relational databases (NOSQL) to store balances is not recommended due to their limitations. Most NoSQL solutions are focused on “consistency in the end,” which is unsafe for monetary transactions where data must be accurate and up-to-date at the time of execution. Also, such solutions do not support multi-line transactions and foreign keys, which greatly complicates ensuring integrity when working with multiple entities, for example, a user's account and its transactions. The lack of a strict data schema and constraints also increases the risk of logical errors and makes auditing difficult.

However, NoSQL databases can be used as an additional component of the system, for example, for temporary caching of information or storing analytical data. However, the source of truth must remain in relational databases.

Based on the above, a relational database is the optimal choice for implementing secure storage of user funds. It provides strict consistency, computational accuracy, integrity control, and audit capability, making it a mandatory element of the financial application architecture, where an error in a single transaction can lead to serious consequences.

For safe and effective storage of information about user funds, the system must use two entities. Transaction log and a table of current balances. The log will keep a complete history of changes for each account and serve as a source of truth to ensure audit and data recovery in case of errors. However, recalculating the balance every time the account is accessed is resource-intensive, as this will increase the load and reduce productivity. Instead, a separate table with the current balance is used for quick access and updated simultaneously with the new operation. Each change must be performed within a single transaction, first the operation is recorded in the log, then the balance is updated, after which both records are confirmed together. This approach will preserve integrity and prevent data loss. In addition, it is necessary to calculate a unique identifier of the operation, which will exclude repeated debiting, and locking the account record will eliminate conflicts during parallel processing. The transaction log will be a guaranteed source of truth, and if necessary, the balance can be recalculated or checked against history. This solution will ensure reliability, performance and transparency.

The next step in building a secure system is to choose an architectural solution, namely, a monolithic or microservice solution [3–8]. In the case of a monolithic version, the key advantage is that operations will be performed within a single database and a single transaction: an event is atomically recorded in the log, the current balance is updated, and the change is recorded. This simplifies integrity, reduces the likelihood of errors or races, and facilitates auditing: all business logic, transaction checks, and locks are concentrated in one place, and the isolation level of the database ensures correctness in competitive queries. The disadvantages include scaling and complete system failure in case of infrastructure problems, the growing code base will complicate releases and future development. In addition, security inside monolith often comes down to code-level checks.

In the case of the microservice approach, the system has the opposite pros and cons. When domains are divided into explicit contours, for example, the accounts and balance service, the payment service, the limits service, and the verification service, each scales independently. Natural data isolation and the principle of least privilege appear. The accounts and balances service has access to managing only accounts and their history, and the payments service accesses it via HTTP or queues, without having direct access to the tables. But there are also disadvantages — the rejection of a common transaction in favor of distributed operation of the application. Debiting and withholding funds turn into a sequence of steps with the exchange of information between the services: a request to block funds, confirmation of the debit, and fixing the debit. There will be delays, repetitions, and failures between operations.

In order to maintain financial integrity, it is necessary to introduce idempotence keys at the business operations level, and use patterns such as transaction outbox for reliable publication of events. It is also necessary to introduce locking mechanisms at the code level and expiring reserves, instead of simple locks at the database level. There are effects such as reading the «just changed» state does not always immediately reflect the fact of the write-off, therefore, agreements on consistency levels, queues of retrays and periodic reconciliations are required.

Monolith is best used where transactional integrity within a single database is critical and latency should be minimal, and the team and domain do not require strict isolation. Microservices are necessary if the load and rate of change are high, and the teams are independent. At the same time, it is necessary to estimate in advance the cost of distributed responsibility, solve problems with the failure of one of the services, guarantee delivery and minimize duplication of events. In practice, systems start with a modular monolith for rapid development and then allocate services when scaling is necessary. This way allows you to take advantage of transactions first, and then get the scalability of microservices without compromising on the security of money.

Conclusion

As a result, we can conclude that reliable storage of user funds should be based on a relational database that ensures transactionality, consistency, and auditability. Dividing the data into different entities will preserve the transparency and performance of the system. At the architecture level, the choice between monolith and microservices is determined by scale and requirements: monolith provides simplicity and reliability within a single transaction, while microservices provide flexibility and scalability, but require additional work to build and maintain the system. The most effective approach is to gradually develop the system from a monolithic structure to a microservice one, which allows you to maintain security and stability while increasing the load and functionality.

References:

1. MySQL documentation. URL: https://www.mysql.com/ Date of visit: 19.10.2025.
2. PostgreSQL documentation. URL: https://www.postgresql.org/ Date of visit: 19.10.2025.
3. Karakhanova.A. Analysis of microservice architecture, monolithic applications, soa architecture / / Synergy Science, 2020. pp. 255–262.
4. Lutsenko D.Yu., Polyakova L. P. Splitting a monolithic application on microservices using the strangler pattern // Information Technologies in Management and Economics, 2021. pp. 82–87.
5. Lokhvitsky V. A., Goncharenko V. A., Levchik E. S.. A scalable microservice model based on a queuing system with «cooling» // Intellectual technologies on transport, 2022. pp. 46–51.
6. Nikitin.V., Gritsenko T. Y. Comparison of the subspecies of monolithic architecture and microservice architecture in the implementation of the server side of web applications // Diary of Science, 2020. p. 22.
7. Kozin A. A., Kharchenko A. V. Architecture of microservices for few teams // Applied Mathematics: modern problems of mathematics, computer science and modeling, 2024. pp. 402–405.
8. Kornienko D. V., Nikulin A. V. Architectural patterns of designing microservices in java // Information technologies in management and Economics, 2024. pp. 150–160.