Blog · 21.07.2026

Data diodes: secure cross-domain data exchange architecture

A guide to secure data exchange architecture using data diodes. Transitioning from synchronous APIs to asynchronous message queues in isolated environments.

Amidst rising cyber threats to critical infrastructure, requirements for network segmentation and protection have significantly increased. According to the ENISA Threat Landscape 2025 report, 53.7% of organizations affected by cyberattacks belong to the category of essential or important entities. In such conditions, implementing data diodes has evolved from a niche solution to a standard architectural requirement for isolating highly secure perimeters.

Why physical air gaps are no longer sufficient and the emergence of data diodes

The classic air gap, defined by NIST CSRC as an interface isolation where data is not directly transferred between systems, provides high security. However, in modern conditions, full isolation is difficult to achieve without disrupting critical business processes.

Data diodes provide a solution by ensuring strict network path isolation while supporting automated exchange. Based on Cross Domain Solutions principles published by NCSC UK, these solutions allow information to be transferred from a secure network to a less trusted one (or vice versa), physically blocking any return traffic or potential Command and Control (C2) communication.

Anatomy of a data diode: why classic REST APIs fail

Developers and architects often face challenges when attempting to integrate standard synchronous APIs (like REST or gRPC) into isolated perimeters. Data diodes enforce a strict one-way traffic flow, eliminating the possibility of a TCP handshake or sending acknowledgment (ACK) packets from the destination to the source.

Any attempt to retrieve an HTTP status or delivery receipt from a secure perimeter results in a timeout error or system hang, as the diode hardware physically blocks feedback. This necessitates a fundamental shift away from synchronous requests.

Architectural patterns for unidirectional exchange: queues, buffering, and asynchronicity

System interaction architecture must be completely rebuilt on unidirectional asynchronous rails using message queues on both sides of the diode. Instead of waiting for an immediate response, the sender ensures data integrity on its side and passes it forward, while the receiver processes the stream autonomously.

Typical examples include:

  • Exporting audit logs from a highly secure internal perimeter to an external monitoring system without the possibility of return traffic.
  • Synchronizing directories or Threat Intelligence streams into a secure enclave where the receiving system cannot acknowledge receipt.
  • Organizing message queues in document management and accounting systems where transactions are registered unidirectionally.

Architectural latency in diode-based systems is typically determined by the polling interval on the receiver side or the batching frequency in the sender's queue.

Error handling and integrity control in zero-feedback environments

Since classic error handling is impossible, systems rely on indirect confirmation via checksums in packets, strict message numbering, and cyclic transmission of critical data. It is important to understand that a data diode only solves the task of network path isolation. It is not a replacement for content filtering, so antivirus checks and data validation remain mandatory at the application and diode proxy levels.

Practical implementation: how UnityBase Defence ensures asynchronous integration between perimeters

To build systems capable of stable operation in the absence of feedback, specialized platform mechanisms are used. An example of such a foundation is UnityBase, a full-stack JavaScript low-code platform (jointly developed by companies within the Intecracy Group, an alliance of independent companies linked by partner agreements and share exchanges, where InBase is a key but not the only developer).

For critical infrastructure, the commercial UnityBase Defence edition is used. It contains ready-made mechanisms for operation in isolated environments:

  • Asynchronous queues (ubq package): Allow systems to record transactions locally without waiting for a response from the receiver's database, supporting batching modes.
  • Integrity control: Defence edition supports applying digital signatures at the object level, allowing the receiver to verify message authenticity without a two-way connection session.
  • Local audit: The DataHistory mechanism ensures reliable security logs and audit trails on each side for subsequent analysis.

Corporate products built on the UnityBase platform, such as the Megapolis.DocNet electronic document management system by InBase and the Scriptum.DMS document management system, have architectures that allow for effective integration into isolated perimeters of government and commercial enterprises.

Comparison of architectural approaches: synchronous API vs. asynchronous queue (data diode)

ParameterSynchronous approach (REST/gRPC)Asynchronous approach (Data Diode / UnityBase)
Transport layerRequires two-way TCP handshake and acknowledgment (ACK)Operates on unidirectional UDP or proprietary physical layer without ACK
Failure responseImmediate error handling on the client sideAccumulation in the sender's buffer (Spooler) until connection is restored
Transaction confirmationReal-time delivery receiptIndirect confirmation via checksums in the packet or full asynchronicity
Security impactRisk of data leakage via return communication channelAbsolute isolation: return path is physically absent

FAQ

How to ensure guaranteed data delivery via data diode without TCP acknowledgments?

In conditions where a two-way TCP handshake is impossible, delivery is ensured through asynchronous message queues, data buffering on the sender side (batching), and the use of checksums. The receiver verifies data integrity locally.

What changes are needed in database architecture to work in a unidirectional perimeter?

It is necessary to completely abandon synchronous request-response patterns. Transactions must be registered locally on the sender side, and synchronization with the target database is performed via unidirectional transmission of serialized events through message queues without return acknowledgment.

How does UnityBase Defence edition solve the problem of state synchronization between isolated segments?

The platform uses built-in asynchronous queue mechanisms (ubq module), local change history (DataHistory), and support for digital signatures for objects. This allows for guaranteeing the integrity and authenticity of synchronized data without the need for a return communication channel.

Data sources

Expert comment

The biggest pitfall when implementing these solutions is trying to force stateful protocols through the gateway. In my experience, success depends on shifting to a fully stateless application architecture; otherwise, the system accumulates errors that cannot be resolved due to the physical absence of feedback.

Anton Marrero, Co-founder, Softline and Intecracy Group

← All materials