Skip to main content

Asset Ordering and Correlation

Summary​

Events carry an occurrence time and a correlation identifier. The relay reads oldest-first, but strict cross-event ordering is not guaranteed by the verified implementation.

Audience​

Engineering, integration, QA, architecture, security, and product reviewers.

Reference Content​

Correlation​

FieldWherePurpose
CorrelationIdContract envelope and outbox rowTrace an event to the originating request
CausationIdContract envelopePresent on the envelope; population policy is not asset-specific
OccurredAtUtcDomain event, contract, and outbox rowEvent time for ordering and audit

The relay's publish metadata includes EventId, EventType, CorrelationId, TenantId, SourceService, and OccurredAtUtc. Correlation identifiers set on the inbound HTTP request can flow into the outbox row for the resulting operation.

Ordering​

AssetOutboxMessageStore.GetPendingAsync returns rows ordered by OccurredAtUtc ascending, capped at the batch size. Within a single relay pass, older rows are published first. However, the verified implementation provides:

  • No total ordering guarantee across batches or across service instances.
  • No per-asset ordering key or partition in the producer.
  • No consumer-side reordering for asset events.

So consumers must not assume strict global or per-asset ordering. Where order matters, the payload's Status and Condition convey the resulting state directly, reducing reliance on delivery order.

Requires confirmation​

Any ordering guarantee expected by a downstream consumer, and the CausationId population policy for asset events, require confirmation.

Source References​

  • microservices/src/shared-kernel/Messaging/OutboxProcessor.cs
  • microservices/src/asset-service/Infrastructure/Persistence.cs
  • microservices/src/shared-kernel/Outbox/OutboxMessage.cs

See Also​

Keywords​

  • Ordering
  • Correlation
  • Occurred-at

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-17
  • Review cycle: Quarterly