Skip to content

Data & Event Platform — overview

Target

This page describes intended behaviour or structure. No implementation is claimed unless a section is explicitly marked Current implementation or Evidence.

Designed 2026-10-09 (design plan P9)

The platform was added on 2026-10-09 (decision D22) so the Data & Event plane owns its foundations as a platform. This page replaces the placeholder overview; the plane's architecture pages (event-driven architecture, data architecture) stay as the narrative they always were and now point at the services that enforce them.

The Data & Event Platform is the Factory's answer to three questions every other platform would otherwise answer differently: what does an event look like and who may publish it, where does data live and who owns it, and how long is anything kept, where, and how does it leave. It is library-shaped: most of its truth also lives in the architecture model and in ConnectSoft.Extensions.MessagingModel and the persistence libraries, and the host makes that truth queryable and enforceable at runtime.
Platform PF-11 Data & Event Platform (Data & Event)
Bounded contexts BC-42
Services 4 (1 hosts, 3 modules, 0 external, 0 later) — 4 modelled
Gateways —
Status target

Purpose

  • One envelope, several carriages. The port-level envelope (ADR-0014: event id, schema version, occurred-at, trusted tenant and project, run, step and attempt where applicable, correlation, causation, producer, type) is identical on every messaging profile; Orleans outbox/inbox, MassTransit on Azure Service Bus and NServiceBus differ only in how they carry it (ADR-0012).
  • One producer per topic, consumers on record. Topics context.area.vN.event-name with payload schema versions and compatibility; a breaking version waits for every consumer's acknowledgement.
  • Separate data classes, one owner each (§54). Operational relational, worker durable, cache, artifact, vector, graph, event transport, audit, analytics and secrets, each on its engine profile per topology, each logical store bound to exactly one owning service.
  • Retention and residency are rules, deletion is an order (D31). Platform ceilings a tenant may shorten; the tenant's region; deletion within 30 days with every owner's receipt; export in open formats.
  • No replay promise, no exactly-once promise. Consumers deduplicate within a window; uncertain outcomes are recorded and reconciled (ADR-0014).

Bounded context and services

Context Owns Services (granularity)
BC-42 Data & Event Foundations Topic and schema registry, envelope profiles, store profiles and bindings, retention and residency rules, governance orders EnvelopeRegistryService (module) · StoreProfileService (module, added) · RetentionResidencyService (module, added)
Host Composition DataEventFoundations (standalone, library-shaped)
Service Context Granularity Status
DataEventFoundations BC-42 standalone host target
EnvelopeRegistryService BC-42 module of host target
StoreProfileService BC-42 module of host target
RetentionResidencyService BC-42 module of host target

Context

flowchart LR
    subgraph P["Data & Event Platform"]
        DataEventFoundations["DataEventFoundations"]
    end
    P --> ext_identity_platform["ext-identity-platform"]
    P --> GovernanceHost["GovernanceHost"]
    P --> ArtifactService["ArtifactService"]
    P --> SecretBrokerService["SecretBrokerService"]
    P --> RunControlService["RunControlService"]
    P --> AuditService["AuditService"]
    P --> AlertRuleService["AlertRuleService"]
Hold "Alt" / "Option" to enable pan & zoom

Containers

See microservices for the container view of hosts and modules.

Store classes and profiles

Class Profile (saas-default) On-prem profile Authoritative
Operational relational Azure SQL, NHibernate (ADR-0006), FluentMigrator per service schema, TenantId by default SQL Server or PostgreSQL yes
Worker durable Azure SQL, separate schema ownership from the control store same yes
Cache and coordination Azure Cache for Redis Redis no
Artifact Azure Blob, content-addressed S3-compatible or file yes
Vector Qdrant (reference) or Azure AI Search (ADR-0013) Qdrant no (derived)
Graph selected later; federated query — no (derived)
Event transport messaging profile (Orleans outbox/inbox default) same n/a
Audit Azure Blob immutable, 7 years WORM-capable store yes
Analytics later (warehouse) — no (projection)
Secrets Key Vault, referenced never copied Vault-compatible yes