Information Mediator - decentralized architecture vs. centralized architecture

An alternative to decentralized system architecture is the deployment of a centralized, country-level Enterprise Service Bus (ESB). In this model, a central authority—typically a governmental IT agency—operates and maintains the ESB infrastructure, assuming full responsibility for all components and operations. All participating entities route their inter-organizational communication through this central ESB.

To expose a service, the central ESB administrators register a proxy service endpoint within the ESB that internally redirects to the actual service hosted by the implementing organization. Consuming organizations invoke the service via the ESB, which abstracts away the underlying service implementation details. Access control policies are centrally managed, allowing the ESB administrators to restrict service access to specific consumers based on pre-defined rules.

Although this centralized model offers strong policy enforcement, centralized monitoring, and audit capabilities, it introduces several significant limitations.

Firstly, by mediating all inter-organizational traffic, the central ESB inherently has visibility into the complete dataset being exchanged across the ecosystem. This creates a serious privacy concern, as the central operator has access to sensitive data, and the centralized message logs become a high-value target for both insider threats and external attackers.

Secondly, this architecture poses scalability and availability challenges. The central ESB must handle the cumulative transaction load of all integrated systems, which can grow substantially, particularly during peak operation periods. This requires a highly scalable and robust ESB infrastructure. Moreover, the central ESB becomes a single point of failure; any outage or degradation in its availability can disrupt the entire interoperability framework and halt all inter-organizational communications.


The second alternative to a centralized architecture is to implement a distributed model using API gateways or security gateways. In this setup, each participating organization deploys and maintains its own gateway, which is used to expose and consume services. This model closely resembles distributed systems such as X-Road, where service provision and consumption are managed locally by each organization.

One of the primary advantages of this architecture is its inherent scalability. Since there is no central communication hub, the system avoids becoming a bottleneck and can scale horizontally as new participants are added. Additionally, the absence of a central node mitigates risks associated with data centralization—no single entity has access to all exchanged data, and there is no central point that can obstruct or surveil data flows.

However, leveraging generic gateway solutions presents certain limitations. The most critical among them is the lack of a standardized framework for interoperability. Each organization is responsible for independently deploying, configuring, and securing its gateway. Establishing trust relationships—such as mutual TLS, certificate exchange, and access control—requires bilateral coordination between each pair of communicating entities. This increases operational complexity and can lead to inconsistent security policies across the ecosystem due to the absence of centralized enforcement or uniform configuration standards.