Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
---
title: "Real-Time Data Sharing"
url: /appstore/services/data-sharing/
description: "Describes the Real-Time Data Sharing capabilities in Mendix, which enable efficient data integration through change data capture."
aliases:
---

## Introduction

Traditional data integration methods often result in delays, inefficiencies, and increased complexity, requiring developers to build custom solutions that handle transaction consistency, error recovery, and schema evolution. Real-Time Data Sharing provides a platform-level solution for data integration through change data capture. Instead of implementing custom replication logic, you specify which entities and attributes to publish, and the runtime handles change detection, streaming, and delivery.

{{% alert color="info" %}}
Real-Time Data Sharing is currently in beta and supported in Studio Pro 11.12 and above.
{{% /alert %}}

## Key Capabilities

* **Data Stream Definition** – Applications define which entities and attributes are published as data streams. Sensitive attributes or irrelevant records can be excluded.
* **Automatic Topic Creation** – On deployment, Kafka topics are created in the Mendix Event Broker. Entity changes (inserts, updates, deletes) are automatically streamed to these topics.
* **Contract Generation** – AsyncAPI 3.0 contracts are generated for each data stream and registered in the Mendix Catalog for discovery.
* **Stream Consumption** – Applications consume data streams by importing AsyncAPI contracts. Received data is stored in the application database and can be transformed using view entities.
* **External System Integration** – Event Broker bridges publish data streams to external systems such as S3 (Parquet files), Azure Blob Storage, or SQS queues.

## Prerequisites

To use Real-Time Data Sharing, you will need the following:

* Studio Pro 11.12 and above
* An event broker; this can be a licensed [Mendix Event Broker](/appstore/services/event-broker/) for apps running in Mendix Cloud

## How It Works

Real-Time Data Sharing uses Change Data Capture (CDC) to detect and publish entity changes from Mendix applications.

Change Data Capture is a pattern that detects database changes and makes them available for downstream processing. Changes are tracked at the data storage layer and published to a message broker or other sink. Downstream systems can be databases, search indexes, caches, analytics platforms, or other consumers.

The Mendix implementation captures domain model entity changes (inserts, updates, deletes) and their associations, then publishes them as change event streams to Kafka topics.

## Architecture Overview

Real-Time Data Sharing is built on Apache Kafka and uses the following components:

* **Change Data Capture (CDC)** – The runtime detects entity changes at the data storage layer
* **Change Event Streams** – Changes are organized into streams, where each stream contains a sequence of change events
* **Event Broker Integration** – Streams are published to Kafka-compatible topics in the Mendix Event Broker
* **Standardized Contracts** – AsyncAPI 3.0 contracts define stream schemas and metadata

### Change Event Streams

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there additional information we should add here?

A change event stream is a sequence of change events for a specific entity type. Each change event contains:

* The operation type (insert, update, or delete)
* The entity state before the change
* The entity state after the change

Change events are published to Kafka topics and consumed by downstream systems.

## Known Limitations

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need additional details on multi-node deployment


Real-Time Data Sharing is currently in beta and has the following known limitations:

* **Multi-Node Deployments**
* **Snapshot Behavior** – Delete events are not included in initial snapshots. Snapshots are only generated for major version changes to the data stream source, not minor version changes.
* **Entity Renaming** – Removing an entity from a data stream and adding it back with a different exposed name in a new version will not produce a snapshot, as the same topic name is reused.
* **Re-Enabling CDC** – If you disable a CDC document and later re-enable it, changes made while it was disabled are not captured or published. Use the force send snapshot feature to resynchronize data after re-enabling.
* **Version Migration with Pending Events** – Migrating to a new data stream version while events remain in the outbox may result in schema mismatches, as the events will be published to the new topic with the old schema.
* **Uncommitted Objects** – Creating an object and canceling the transaction (without committing) may produce a delete event.
* **Inherited Properties** – Inherited properties are not supported.

## Read More

Read more to learn how to configure and deploy Real-Time Data Sharing in the following documents:

* [Real-Time Data Sharing Configuration](/appstore/services/data-sharing-configuration/)
* [Deploy Real-Time Data Sharing](/appstore/services/data-sharing-deployment/)
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
---
title: "Real-Time Data Sharing Configuration"
url: /appstore/services/data-sharing-configuration/
description: "Describes how to configure Real-Time Data Sharing to publish data streams from your Mendix application."
---

## Introduction

This document describes how to configure Real-Time Data Sharing in your Mendix application to publish entity changes as data streams.

## Modeling

### Modeling the Change Event Stream

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does this occur in Studio Pro?

Studio Pro provides interfaces to model which entities and associations are published as change event streams.

Configuration options include:

* Field selection – specify which attributes are published
* Reference handling – publish denormalized data (embedded) or normalized data (references only)
* Partition keys – configure keys to divide streams into partitions for parallel processing

Ordering is guaranteed within a partition. Events with different partition keys may be processed in parallel.

### Contract Definition

Each data stream has an associated contract that defines:

* Stream metadata (name, version, description)
* Schema definition (field names, types, constraints)

#### Exporting the Contract

Contracts are exported as AsyncAPI 3.0 documents with the following mappings:

@quinntracy quinntracy Jun 23, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a note in the original document about further explanation on Async API 3.0 being used in change stream contracts and how the fields are mapped. Will that be added here or elsewhere?


* Streams → AsyncAPI channels
* Change events → AsyncAPI messages

## Event Broker Configuration Settings

Event Broker and Kafka-compatible systems provide multiple configuration options beyond basic constants. Event Broker configuration is available in app settings, similar to database or workflow configuration.

### Connection

@quinntracy quinntracy Jun 23, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the user need to follow any additional steps to configure? We will want to provide further instruction on where this happens in the Event Broker (where to go in the Settings, potential screenshots)

Configure the following connection settings:

* **Server URL** –
* **Authentication** – Username and password

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any additional information needed for the server URL?

* **Authentication Type** – Mendix Cloud, SASL, AWS, Confluent, or other compatible authentication mechanisms

### Publishing

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any additional information needed?

Configure publishing behavior:

* **Timeouts** – Timeout values for publishing operations
* **Queue Size** – Maximum queue size for pending events in the outbox

### Topic Naming

Configure how streams map to Kafka topics:

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any additional information needed?


* Topic prefix – optional prefix for all topics
* Topic pattern – custom naming pattern for topics

### Consumer Groups

Configure consumer group IDs for each topic.

## Metamodel

The current metamodel has limited support for expressing streams as a concept. Future versions may introduce native stream representations rather than adapting existing metamodel components.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably focus on just what the current metamodel can do, as we do want to promise what a future may or may not be able to do.


## Read More

* [Deploy Real-Time Data Sharing](/appstore/services/data-sharing-deployment/)
* [Mendix Event Broker](/appstore/services/event-broker/)
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
---
title: "Deploy Real-Time Data Sharing"
url: /appstore/services/data-sharing-deployment/
description: "Describes how to deploy Real-Time Data Sharing and publish data to data lakes and other systems."
---

## Introduction

This document describes deployment options for Real-Time Data Sharing, including CDC implementation approaches, runtime architecture, and integration with external systems.

## CDC Implementation

Two approaches are available for implementing change data capture in Mendix applications.

### Using Runtime Data Storage Triggers

The runtime data storage layer detects entity changes and publishes them directly. This approach:

* Works consistently across all supported databases
* Avoids deployment complexity by integrating CDC into the existing runtime
* Operates at the domain model level rather than the database level
* Supports all domain model features including view entities

### Using an Independent CDC Component

An external CDC component (such as Debezium) reads database changes from the Write Ahead Log (WAL) and publishes them to Kafka. This approach has several limitations in the Mendix context:

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way this reads seems to encourage users to use the Mendix Runtime to implement. Is that the goal, or can a user effectively use an independent CDC component? We may want to rephrase this section to state more that it is possible to use an independent CDC but have a warning box that explains the challenges they may encounter.


* The platform does not natively support multi-component runtime deployments
* Debezium does not support all databases that Mendix supports
* The Mendix domain model does not map directly to the database schema, requiring additional transformation logic
* A stream processor would be needed to apply the same data storage logic as the runtime, creating tight coupling
* Domain model features like view entities are not represented as database tables

## Data Streaming Primitives

### Kafka Producer

The Kafka producer publishes change events to the Event Broker. The producer is configured using the settings described in [Real-Time Data Sharing Configuration](/appstore/services/data-sharing-configuration/).

### Kafka Consumer

The Kafka consumer reads change events from topics and maps them to Mendix entities in the consuming application's database.

## Publishing Change Event Streams to Event Broker

The publishing flow consists of the following steps:

1. Data storage detects entity changes (inserts, updates, deletes) for published entities.
2. Change events are queued in the outbox.
3. The producer dequeues events, encodes them as Kafka messages, and publishes to the Event Broker.

The outbox pattern ensures reliable delivery. Events are persisted locally before publishing, and remain in the outbox until successfully delivered.

## Historical Data and Snapshots

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was an additional to-do in this section "ADR on snapshots." What else needs to be added and will it be here or elsewhere?


Change events capture incremental updates. To provide the complete current state of entities, a snapshot is triggered during the initial deployment. The snapshot publishes all existing entity records as insert events. Snapshots are not triggered on subsequent application restarts.

## Compacted Topics

Kafka log compaction retains only the latest event for each entity key. This reduces storage requirements and allows new consumers to catch up faster by reading only the current state rather than the full change history.

## Message Format

CDC message formats lack standardization. The Debezium format is commonly used for database change events. Cloud Events (used by Business Events) is less common for CDC use cases. The message format will be determined during implementation.

## Publishing Change Event Streams to Third-Party Systems

### Mendix Cloud

The Event Broker Bridge feature supports publishing data streams to external systems. Extending the existing bridge implementation to support data streams maintains a consistent integration pattern.

### BYOK Model

For deployments outside Mendix Cloud, bridges are not currently available. To support all deployment models, bridges could be defined in Studio Pro and transformed at build time into configurations for Kafka connector systems (for example, Kafka Connect, Bento, Redpanda Connect). This requires further design work based on customer requirements.

## Non-Functional Requirements

Real-Time Data Sharing addresses the following non-functional requirements:

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to expand upon these requirements (explain them in further depth) or just list them as they currenty are below?


* **Exactly-Once and Ordered Delivery**
* **Elasticity**
* **High Throughput and Low Latency**
* **Durability**
* **Data Correctness for Downstream Mendix Systems**

## Read More

* [Real-Time Data Sharing Configuration](/appstore/services/data-sharing-configuration/)
* [Mendix Event Broker](/appstore/services/event-broker/)
* [Event Broker Bridges](/appstore/services/event-broker/#manage-mx-broker-bridge)