Skip to main content

Payroll Outbox and Delivery

Summary​

This page documents confirmed payroll outbox and delivery behavior and explicitly marks incomplete integration boundaries.

Audience​

Payroll and integration developers, QA and support engineers, solution and security architects, and implementation partners.

Outbox model​

Outbox records retain message/event identity, type, serialized contract, occurrence time, status, processing time, retry count, bounded failure detail, correlation, tenant metadata, and source.

SaveChanges participation​

The event intent is atomic with each confirmed native Payroll operation. Status updates by the shared processor use later SaveChanges calls.

Relay and processing​

The shared processor reads Pending and Failed records in occurrence order, publishes one at a time, and records Processed or Failed state. The store increments retry count on failure. A Payroll-hosted execution loop is Requires confirmation.

Retry and replay​

Failed records remain eligible for later processing. No Payroll-specific attempt limit, delay policy, dead-letter transition, manual replay workflow, or purge policy is confirmed.

Delivery claim​

Guaranteed, exactly-once, and ordered delivery are not claimed. A successful publish result and a later status save are separate operations.

Operational ownership​

The shared kernel supplies the processor; Payroll supplies the store. Runtime ownership and alerting require confirmation.

Source References​

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

See Also​

Keywords​

  • Payroll events
  • Payroll Outbox and Delivery
  • Integration contracts

Revision Information​

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