Skip to main content

Expense Event Idempotency and Ordering

Summary​

Expense delivery is at-least-once in effect: failed publication remains eligible for retry, and consumers protect their own work by event identity. Exactly-once and global ordering are not implemented.

Identity and duplicate handling​

  • Each domain event receives an identity, but the mapper creates a different integration-event identity.
  • Outbox event identity is unique within Expense persistence.
  • A duplicate workflow callback does not raise a second domain event.
  • Payroll records successfully synchronized event identities and ignores duplicates.
  • Notification checks a unique processed-event identity before dispatch.
  • Expense's processed-event ledger is unused because Expense has no inbound consumer.

Ordering findings​

Payroll also compares occurrence time for an existing claim projection and ignores older events. Notification has its own configurable stale-event policy. These consumer safeguards are not a broker ordering guarantee.

Correlation and causation are defined by the envelope but Expense mapping currently leaves them empty. No partition key, per-claim broker ordering, global order, replay sequence, or exactly-once guarantee is confirmed.

Requires confirmation​

Partition strategy, ordering objectives, correlation enrichment, replay identity rules, and deduplication retention require confirmation.

Source References​

  • microservices/src/expense-service/Domain/Expense/ExpenseDomainEvents.cs
  • microservices/src/expense-service/Infrastructure/ExpenseDbContext.cs
  • microservices/src/expense-service/Infrastructure/Persistence.cs
  • microservices/src/payroll-service/Messaging/PayrollReadModelConsumer.cs
  • microservices/src/notification-service/Application/NotificationDispatcher.cs

See Also​

Keywords​

  • Expense events
  • Idempotency and Ordering
  • Integration contracts

Revision Information​

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