Between 2000 and 2012, an architecture in which business logic was concentrated in stored procedures and database functions was regarded almost as a default standard. Given the limited bandwidth of communication channels at the time, the principle that logic should reside where the data itself was stored appeared not merely rational, but technologically necessary. It reduced network latency and eased the load on infrastructure. Yet what once functioned as an engineering advantage has increasingly become a source of systemic constraint. Formerly solid monolithic solutions have turned into an architectural brake, and for fintech, the modernization of IT infrastructure has long ceased to be a matter of convenience. It is now a matter of resilience and, without much exaggeration, survival.
The central problem of the database-centric model today lies in the fact that business logic becomes tightly embedded in the data storage environment. When key banking processes are hardwired into database procedures, the business, in effect, becomes dependent on its own outdated architecture. This dependency becomes especially painful under conditions of growing load. Horizontal scaling of such a system is extremely difficult: sooner or later, the organization runs into the physical performance limits of a single database server. Dependence on a specific DBMS vendor is no less dangerous. As capacity grows, total cost of ownership begins to rise disproportionately, while vendor lock-in turns from a technical nuance into a serious financial factor. Another troubling tendency is added to this picture: the shortage of specialists capable of maintaining PL/SQL code. The labor market for such expertise is narrowing, which means that personnel risk grows alongside technical debt.
Against this background, moving business logic to the application layer appears to be a logical and, in many cases, unavoidable decision. Extracting algorithms and decision-making rules from the SQL environment into backend architecture makes it possible to separate logic from the mechanism of data storage. This changes the quality of the system itself: full-scale automated testing becomes possible, maintenance becomes simpler, and critical dependence on a particular DBMS decreases. In other words, architecture stops being a cage in which the business is locked and once again becomes an instrument of development.
The weaknesses of the database-centric approach become especially visible in release processes. CI/CD for logic embedded in the database has historically been limited. In a classic legacy scenario, the implementation of changes is reduced to deploying SQL scripts and PL/SQL packages. In a microservice environment, rolling back to a previous artifact version may take only seconds. In a database, however, an error often affects not only the code, but also the structure of tables. In such a situation, rollback requires either restoration from backups or the creation of compensating scripts, and that already creates a direct risk of downtime and data loss. Moving logic into backend services makes the release cycle significantly more transparent and safer. It is telling that even the automation of Oracle BI Publisher template deployment through CI/CD in large corporate systems has already shown how radically the influence of human error during deployment can be reduced.
Over the past decade, the banking sector has undergone a notable architectural evolution: from a collection of fragmented interfaces, it has moved toward unified front-office platforms. Backend services made this transformation possible. Moreover, they opened the way to integration with external data sources, including, for example, social platforms, which is especially important for modern banking scoring models. Implementing such work inside database procedures is almost impossible, or at the very least highly inefficient. In a distributed environment, the combination of orchestration and event-driven choreography through message brokers gives the system a level of fault tolerance that a monolithic database-centric model simply does not possess. If the database becomes temporarily unavailable, caches and microservices can continue to perform a substantial part of the functionality. A monolith, by contrast, stops as a whole. It is hardly surprising, then, that the next step is a gradual move away from heavy enterprise service buses toward independent, loosely coupled microservices.
The limitations of logic located inside the database become even more pronounced in trading systems and infrastructure for exchange bots, where the cost of latency is measured not merely in milliseconds, but in direct financial losses. In such systems, placing logic in database procedures is practically unacceptable. The first reason is latency. Each procedure call involves a network round-trip and additional overhead associated with SQL processing, while in trading even a minimal delay may become critical. The second reason is locking. When thousands of bots interact with the system simultaneously, the database inevitably becomes a bottleneck. Locking mechanisms typical of relational DBMSs form queues and then trigger a chain reaction of degradation across the entire platform. For this reason, logic in such scenarios is moved into backend microservices, while In-Memory solutions such as Hazelcast or Redis are used for operational data storage. Keeping quotes and orders in RAM provides near-instant access, and orchestration through Kubernetes allows the system to withstand sharp spikes in activity without performance degradation.
Ultimately, the advantage of moving business logic from the database into distributed microservices lies in the possibility of horizontal scaling. Scaling the database itself almost always remains expensive, complex, and tied to the vertical expansion of hardware resources. In other words, the organization is forced into a continuous race for increasingly powerful hardware in order to scale vertically. The backend in a cloud container environment operates according to a different logic: it can be expanded flexibly, quickly, and, within available resources, almost without an upper ceiling. Autoscaling mechanisms in AWS, Azure, and GCP make it possible to change the number of nodes within minutes depending on current load. For this reason, the transition to a flexible distributed architecture should now be viewed not as a technological fashion, but as the only realistic way to preserve stability and competitiveness in an environment where speed has become the decisive factor.
