Skip to main content
In this section

Data Mesh — federated data streaming between platform tenants

ExplanationPublic

The problem this solves​

Multi-tenant platforms create data silos by design. Each team runs its own services, its own databases, and its own pipelines — and when one team needs data from another, the answer is usually a one-off API integration, a manual export script, or a shared database that turns into a coupling nightmare.

Building and maintaining bespoke ETL pipelines for every cross-team data flow doesn't scale, is hard to audit, and breaks silently when schemas change.

SmoothGlue Data Mesh gives teams a platform-native, self-service way to publish and subscribe to data streams — without requiring a dedicated data engineering team or custom infrastructure.

What Data Mesh is​

Data Mesh is SmoothGlue's federated data streaming layer. It lets platform tenants publish structured data from their services and subscribe to data published by other tenants — without direct service coupling or shared databases.

The model is producer/consumer: a team declares what data they publish (an origin), and other teams declare what they want to receive (a destination). The platform handles the transport, transformation, and delivery.

This is not a data warehouse or a batch ETL tool. Data Mesh is designed for continuous, event-driven data flows between live services running on the platform.

How it works​

Publication and subscription model

Tenants interact with Data Mesh through three Kubernetes custom resources:

  • xdatamesh — the top-level resource that defines a data mesh instance
  • xpublication — declares a data origin: what data is being published and from where
  • xsubscription — declares a data destination: who receives what, and how it is transformed

This declarative model means data flows are version-controlled, auditable, and self-documenting. Adding a new consumer does not require changes to the producer.

Transport layer

Under the hood, all data flows through NATS JetStream — a high-throughput, persistent messaging system built for distributed environments. JetStream provides at-least-once delivery guarantees, durable streams that survive consumer restarts, and backpressure handling for slow consumers. This means data is not lost if a destination service is temporarily unavailable.

Processing engine

The datamesh-core service processes all data in motion. It is a Go-based engine forked from Benthos, purpose-built for the platform's reliability and security requirements. Transformations between origin and destination are expressed in Bloblang — a domain-specific language for field mapping, filtering, and restructuring structured data — keeping transformation logic portable and readable without custom code.

Configuration UI

Platform operators and tenant teams configure data flows through the SmoothGlue Console using guided setup wizards: a 5-step flow for defining an origin and a 6-step flow for configuring a destination. The Console generates the underlying Kubernetes resources automatically.

The backend is a Django REST API; the frontend is a React application embedded in the SmoothGlue Console.

What's pre-integrated​

CapabilityWhat SmoothGlue provides
30+ input connectorsDatabases, S3-compatible object storage, Kafka topics, HTTP endpoints, and more — available out of the box as origin sources or destination sinks
Bloblang transformsBuilt-in transformation language; no custom code or separate transformation service required
Console wizardGuided UI for origin and destination setup — no direct Kubernetes resource authoring needed for standard flows
NATS JetStreamPre-deployed, pre-configured; persistent streams and at-least-once delivery are on by default
Kubernetes integrationXRDs are registered at platform install; data mesh resources are first-class platform citizens

What you still own​

  • Your data schemas and how they evolve over time
  • Bloblang transformation logic specific to your use case — the platform runs it, you write it
  • Retention policies for your published streams
  • Access decisions: which tenants are permitted to subscribe to your publications
  • Source and destination credentials (stored in Vault, but created and managed by your team)

Learn more​