| ID | product.device_management.registry_service |
|---|---|
| Description | Source of truth for devices and their state. |
| Key | registry_service |
| Type | microservice:service |
| Team | Device Management |
| Owner | device-mgmt@iotgateway.example |
| Status | active |
| Technologies | Go, PostgreSQL, gRPC |
| Attributes | api_style: REST + gRPC, rps: 8k |
| Tags |
The Device Registry answers the question every other service eventually asks: “is this a real, active device, and what is its current state?” It owns the device record, the certificate that proves a device’s identity, and the twin — the desired vs reported state of each device.
Why a single source of truth
Ingestion, OTA and the dashboards all need a consistent answer about a device. Centralising identity and twin state here keeps those answers authoritative and auditable instead of scattered across services.
Could not build diagram for model "example-iot".
When a device opens an MQTT session, Ingestion asks the registry to confirm the certificate maps to an active device record.
The Connection State Tracker flips a device online/offline as sessions open and close; reported twin values are written by ingestion as telemetry arrives.
Operators (via the apps) set desired twin values — e.g. a sampling interval — which the edge agent reconciles against on its next sync.
The registry exposes a small REST/gRPC surface for fleet lookups and twin updates. The full contract is embedded below on the Overview tab.
Mutations to the twin are idempotent and versioned: a stale If-Match
version is rejected so concurrent operators cannot clobber each other.
1 workflow
| Workflow | Model | Participant id | Participant label |
|---|---|---|---|
| Device provisioning device-lifecycle.provisioning | example-iot | product.device_management.registry_service | Device registry |