---
title: Integrating Event Driven systems
url: https://www.grahambrooks.com/event-driven-architecture/patterns/integrating-event-driven-systems/
date: 2017-06-24T11:14:50-06:00
author: Graham Brooks
description: It is very rare for an application or system to exist in isolation. Systems need to be integrated to deliver business value.
tags:
- architecture
series:
- event-driven-architecture
---

# Integrating Event Driven systems

```asciidoc

= Integrating Event Driven Systems
:permalink: "/event-driven-architecture/patterns/integrating-event-driven-systems"
:code: _code-samples/functional-event-store
:icons: font

'Event driven' is used to describe a wide range of application and system architectures so it is important to define some context. 

icon:tag[]: Event driven distributed systems that use asynchronous exchange of events to deliver business functions.


When integrating with an other system I like to keep the exposed
integration surface area as low as possible. What I mean by this is
that only the required functions are available to the application and
that the API is not directly accessed by the software that I am
writing. In short - facade the provided API.

image:/images/integrating-event-systems-1.svg[align=center, width=100%]

Adding an adapter is arguably 

This has several advantages;




There are many ways to integrate systems. The seminal work in this space is Gregor Hope book - enterprise integration patterns.

Ingegrating systems that have completely different architectures
requires a mapping layer that addresses these compatibilty
issues. Asynchronous event driven systems typically encounter these
challenges.

image:/images/integrating-event-systems-2.svg[align=center, width=100%]


Batch data exchange has been the mainstay of system integration for
decades. To be successful event driven systems need a way to work with
systems that rely on bulk, infrequent exchanges of data i.e. Batch.

When we exchange data each systems has to reconcile the received data
against its current view.

[cols="2,^,2,5"]
|===
|System A
|=>
|System B
|System B has no representation of a record received from System A. System B creates a representation of the data based on the record in the file.

|System A
|<=
|System B
|System A has no representation of a record received form System B. System B creates a representation of the data based on the record in the file.

|System A
|<==>
|System B
|System A and B had the same representation so no action required.

|System A
|<=/=>
|System B
|System A and B both have a version of the data record but disagree in the values.
|===

When the two systems have different data representations we need to do
more work to reconcile the differences. Simple reconciliation might
involve time-stamp for when the data changed or to choose one system as
the system of record.

Time-stamp reconciliation:: uses a time-stamp generated by the source
system placing the change on a time-line. Using the latest time-stamp
means that the last change wins.

System of record reconciliation:: One system is chosen as the system
of record. This could be system A or B. Whichever one is chosen as the
system of record is taken as truth and the other system honors the
state.

System of record reconciliation becomes more complex when we control
the system of record but the system we are integrating with does not
honor that decision. If that's the case then the system of record
would need to update the system directly using an API.

Quite often batch data exchanges can be delayed because they rely on
everything being in place infrequently. File formats change, data
problems occur during preparation, data transfer and availability
changes. Typical batch cycles of 24 hours can often end up being days.

Batch data comes in two flavors. Point in time state and logs. State
data is typically the systems view at the point the file was
generated. Be cautious about using the generation time for time based
reconciliation because batch data takes time to prepare.

Log data files are a record of changes since the last file was
generated. Log data is very similar to events - a point in time record
of state. While attractive (from an event point of view) it is
unlikely that event data boundaries between systems will
match up. Some time ago working with a change log from an external
system the system listed field changes first name, second name, date
of birth. Our system had events for name change. This meant that field
level changes had to be combined with other field changes or existing
state so we could generate appropriate events.

Typical Integration patterns

image:/images/integrating-event-systems-3.svg[align=center, width=100%]


.Direct Call integration
image:/images/integrating-event-systems-4.svg[align=center, width=100%]

In this pattern each service that needs to integrate with the external
service or system does so independent of the other services. Changes
in the service only affect a subset of the interaction. Changes to the
integrated service require changes to all the services that are
affected.

It is challenging to maintain a complete separation between event
driven behavior and the integrated system. Concepts and data items
naturally leak out of the API and start to invade the event service
data model.
```