Integration Gateway for External Systems

Florin Coros -

Code Design Example from a Real ETRM Platform

When building large-scale distributed systems, integration with third-party platforms is often one of the most sensitive and critical aspects. These external dependencies can easily become points of failure or sources of complexity if not handled properly. In this article, we explore a Code Design approach for implementing an Integration Gateway that helps isolate and standardize external communication.

The Role of the Integration Gateway

The Integration Gateway is a dedicated layer of services responsible for managing all interactions with systems outside our control. These may include TSOs (Transmission System Operators), Power Exchanges, asset control platforms, or data providers.

These integrations often share common technical requirements—security, monitoring, reliability, fault tolerance, diagnostics, and performance. At the same time, each external API has its own peculiarities. The Integration Gateway is designed to bridge that gap: it speaks the language of each external system while translating everything to a common contract understood by our core platform.

This approach protects the internal system from changes, errors, and unexpected behaviors coming from external parties.

Real-World Context: Technical Design for an ETRM System

As part of a greenfield development project in the energy sector, I led the software design and implementation of a platform that enables grid balancing entities to:

  • Trade ancillary services with TSOs
  • Buy and sell energy on Power Exchanges
  • Monitor and control production or consumption assets

The system had to be multi-tenant, support multiple countries and energy markets, and run either as an on-premise solution or in the cloud using a SaaS model.

The Integration Gateway became a key part of this software design, as we needed to connect to many different external platforms while enabling customers to license only the specific integrations they required.

Technical Design Approach

To ensure maintainability and predictability, we applied a mix of Code Design patterns and supporting infrastructure:

  • Contract-First Approach
  • Pluggable Application Structure
  • Runtime Type Discovery
  • Clean Architecture Principles

These decisions shaped both the detailed design and the structure of our codebase, offering strong separation of concerns and promoting reusability.

Contract-First Design

We defined interfaces at two different abstraction levels:

  1. Internal Contracts – describing what our system expects from the external integration (e.g., data or behavior needed from a TSO)
  2. External Contracts – defining what each adapter needs to fulfill when connecting to a specific external API

All contracts were isolated in "Contract Assemblies"—assemblies that include only interfaces, DTOs, and exceptions, without any logic.

This separation ensured loose coupling and clarity at the design level.

Pluggable Applications

Each external system (e.g., each TSO or Power Exchange) had a dedicated adapter packaged as a separate assembly. These acted as plugins.

The adapters translated between the contracts we defined and the actual APIs provided by the external parties.

At runtime, different versions of the same integration service (e.g., for TSOs) were deployed, each with its own plugin based on customer-specific configuration.

This allowed us to maintain a single codebase and dev team per integration type, while deploying multiple services for scalability, fault isolation, and operational independence.

Runtime Type Discovery

We used a type discovery mechanism to detect and register all plugin implementations at application startup.

When a service instance launched, it scanned all loaded assemblies and registered relevant implementations into the Dependency Injection container based on naming conventions.

This enabled us to customize deployments and behaviors without needing to recompile the application.

A lightweight implementation of this pattern can be found in our GitHub account part of the AppInfra-Training repository.

Clean Architecture

A core idea behind Clean Architecture is that business logic should be independent of frameworks or external SDKs.

In this Integration Gateway, the core logic did not reference any third-party libraries. Only the plugin assemblies were allowed to depend on SDKs provided by TSOs or Power Exchanges.

This separation made the codebase easier to test, maintain, and evolve.

Summary

In distributed platforms that rely on third-party services, the Integration Gateway acts as a protective boundary. It translates diverse external protocols into a common language, making the system resilient and maintainable.

By applying Contract-First principles, pluggable structures, runtime discovery, and Clean Architecture, you can build integration layers that scale, adapt, and hold up over time. This kind of technical design is essential when building modern platforms that must remain robust in the face of constant external change.

This example showcases how disciplined software design and clear separation of concerns can support both flexibility and control in real-world systems.