Eclipse Ditto consists of five microservices that communicate over a Pekko cluster to provide digital twin management, access control, search, and connectivity to external systems.
Overview
The architecture of Eclipse Ditto is built around five cooperating microservices, each with a clear responsibility. This page describes the top-level component view, how services are defined, and how they communicate.
How it works
Component view
The five services and their responsibilities:
| Service | Responsibilities |
|---|---|
| Policies | Persist and enforce (authorize) Policies |
| Things | Persist and enforce (authorize) Things and Features |
| Things-Search | Track changes to Things, Features, and Policies; maintain an optimized search index; execute search queries |
| Gateway | Provide HTTP and WebSocket APIs |
| Connectivity | Persist Connections; send and receive Ditto Protocol messages to/from external message brokers |
All services run in the same Pekko cluster and reach each other via TCP without requiring an additional message broker between them.
Microservice definition
Each Ditto microservice follows three rules:
- Own data store: Only the owning microservice can access and write to its data store.
- Signal-based API: The service exposes its API as signals (commands, command responses, events).
- Signal-only access: Other services interact with it exclusively through these signals.
Communication
All microservices communicate asynchronously within the Ditto cluster using Pekko remoting. Each service acts as both a TCP server (accepting connections) and a TCP client (sending messages to other services).
All messages sent between services are serializable. Ditto signals serialize from Java objects to JSON and deserialize back from JSON to Java objects.