Legacy systems often become the primary barrier to digital transformation, necessitating a shift from fragile point-to-point connections to structured, scalable integration layers. When business demands require the rapid launch of new digital services, architects and CTOs often find themselves trapped in "spaghetti integrations." Direct system-to-system links create unmanageable technical debt, prevent scaling, and block security audits. However, completely rewriting monoliths is rarely financially viable. A rational approach involves isolating the legacy core and building a modern integration layer.
Anatomy of spaghetti integration: why point-to-point connections block IT landscape development
Historically, enterprise system integration followed the path of least resistance, with developers creating direct database connections to transfer information. As the IT landscape grows, this approach becomes a significant liability.
An increase in point-to-point integrations leads to quadratic complexity growth—O(n²). Any change to a data schema in one system breaks adjacent services due to the lack of a unified data contract and intermediaries. Transitioning from point-to-point to a hub-and-spoke architecture reduces complexity to O(n), where each system interacts exclusively with a central integration layer.
Beyond operational complexity, direct connections create critical security risks. According to the ENISA Threat Landscape 2025 report, digital infrastructure and services accounted for approximately 27.7% of data breaches between July 2024 and June 2025. A significant portion of these incidents is linked to unsecured integration interfaces that prevent centralized auditing.
Theoretical foundation: applying Message Translator and Content-Based Router patterns by Hohpe & Woolf
To solve the problem of spaghetti integrations, architects rely on concepts described in the Enterprise Integration Patterns (EIP) work by Gregor Hohpe and Bobby Woolf. They formalize the integration of messaging systems through channels, routers, and transformers, which significantly reduces coupling.
Two key patterns for modernizing legacy integrations:
- Message Translator: Legacy systems often use proprietary or specific data formats. A Message Translator converts these formats into standardized ones (e.g., JSON), making them understandable for modern microservices.
- Content-Based Router: Allows a sender system to transmit messages into a single channel. The router analyzes the content and dynamically redirects data to the appropriate recipients, freeing systems from needing to know each other's addresses.
From chaos to contract: building an API layer using a Domain metadata-model
Real modernization begins by replacing hard-coded direct database connections (e.g., between a legacy ERP and new microservices) with a centralized API layer. To centralize security functions, rate limiting, and observability, an API Gateway (such as Kong) is typically used. The overhead of such a gateway is measured in low milliseconds, which is perfectly suitable for enterprise transactional systems.
However, an API Gateway only manages traffic and does not solve the mapping problem of complex legacy database structures. For this, a Domain metadata-model approach is used. Instead of manually coding integrations for every table, a declarative description of entities and their relationships is created, serving as a source for automatic REST API generation.
As an example of such an integration hub, consider the UnityBase platform (a joint development by the companies of Intecracy Group, an alliance of independent companies linked by partner agreements and share exchanges, where InBase is a key but not the sole developer). UnityBase allows wrapping legacy data into a unified Domain metadata-model. The platform uses its own DBMS-agnostic ORM, which automatically generates a REST API based on the described metamodel. This enables external services to interact with legacy data through a modern contract without interfering with the monolith's code or database.
Security of legacy data: implementing RBAC, RLS, and end-to-end auditing without rewriting the monolith
Often, old monolithic DBMSs do not support modern access control mechanisms. Instead of attempting to implement Row-Level Security (RLS) within the legacy system's code, security policies are centralized at the API layer.
By applying centralized RBAC (Role-Based Access Control) and RLS policies, the integration platform automatically modifies SQL queries to the legacy database, adding necessary filters according to the permissions of a specific user or microservice. Simultaneously, end-to-end auditing (audit trail) is ensured by logging every action.
In projects with high security requirements (high-load, B2G, or critical infrastructure), it is advisable to use Enterprise or Defence editions of platforms like UnityBase. These extend basic functionality with Active Directory integration, support for one-time passwords (OTP), digital signature processing (RSA/DSTU), and stricter traffic encryption policies.
Transitioning to event-driven: when event streaming and event replaying are needed
In cases where synchronous API integration creates a risk of cascading failures (due to a high volume of sequential requests), architects turn to Event-Driven Architecture (EDA). A prime example is using events to decouple legacy core banking systems from modern mobile applications interacting with customers.
Using event streaming platforms like Apache Kafka, systems exchange states asynchronously. A key advantage of this approach is replayability—the ability to replay events. This allows new services or audit modules to "replay" transaction history and accurately reconstruct the system's current state from a past point in time.
It is important to remember that EDA is not a universal solution. For processes requiring instantaneous synchronous transactions with low latency, traditional synchronous APIs remain more optimal.
Comparison of legacy integration modernization strategies
| Comparison parameter | Direct integration (Point-to-Point) | API layer on metamodel (UnityBase) | Full rebuild (Event-Driven) |
|---|---|---|---|
| Implementation complexity | Low at start, critical over time | Medium (rapid wrapping of existing data) | High (requires paradigm shift) |
| Impact on legacy core | Direct interference with DB/code | Zero (read/write via API contract) | Requires implementation of CDC mechanisms |
| Security level (RBAC/RLS) | Decentralized, difficult to control | Centralized at platform metamodel level | Centralized at bus/broker level |
Modernizing legacy systems is an evolutionary process. Applying proven EIP patterns, implementing domain metamodels for API generation, and gradually transitioning to event streaming allow businesses to preserve investments in legacy systems while gaining the necessary flexibility and security.
FAQ
How can a modern microservice be connected to a legacy ERP without the risk of breaking the database?
It is necessary to replace hard-coded point-to-point connections with a centralized API layer. Using a Domain metadata-model, a secure REST API is created that interacts with the legacy database via a DBMS-agnostic ORM without changing the ERP's own code.
How can Row-Level Security (RLS) be implemented for legacy data if the old DBMS does not support it?
RBAC and RLS policies are implemented at the integration hub level. The platform analyzes user roles and dynamically adds the necessary filtering conditions to SQL queries before they are sent to the legacy database, ensuring centralized access control.
Which Enterprise Integration Patterns are best suited for decoupling a monolith?
The most effective are Message Translator for converting proprietary legacy formats into standardized ones (e.g., JSON) and Content-Based Router for dynamic message routing without the need for hard-coding recipient system addresses.