Event Idempotency

Summary

This page records the verified Workforce Scheduling event boundary and its adjacent Attendance integration behavior.

Audience

Developers, integration engineers, database engineers, QA engineers, and solution architects.

Reference Content

Producer-side outbox storage has a unique event-identifier index. The Integration Service also persists one processed record per event identifier, checks it before dispatch, audits duplicates, and skips an already completed event.

This protection is scoped:

• no general Inbox abstraction was found in Attendance or scheduling code;
• uniqueness does not prevent the same business action producing different event identifiers;
• a crash after downstream delivery but before the processed record is saved can repeat downstream work;
• idempotency of configured downstream targets is not proven;
• Notification Service has its own dispatcher behavior, but it does not subscribe to scheduling or Attendance types.

Scheduling commands rely on their synchronous validation and persistence rules, not event idempotency.

Source References

• microservices/src/attendance-service/Infrastructure/AttendanceDbContext.cs
• microservices/src/integration-service/Domain/IntegrationEntities.cs
• microservices/src/integration-service/Orchestration/EventDispatcher.cs
• microservices/src/integration-service/Infrastructure/IntegrationDbContext.cs

Related Articles

• Events overview
• Event limitations
• Event source map

See Also

• Technical documentation
• API documentation
• Database documentation

Keywords

• Workforce Scheduling events
• Attendance integration contracts
• Transactional outbox

Revision Information

• Status: Draft
• Last reviewed: 2026-07-20
• Next review: 2026-10-20