Processed Event Storage

Summary

ProcessedIntegrationEvent ledger mapping and current absence of a local consumer.

Audience

Backend engineers, database reviewers, architects, QA, support, operations, security reviewers, and product owners.

Overview

ProcessedIntegrationEvent is persisted as an operational idempotency ledger for future inbound integration consumption. The object exists even though no Performance message consumer currently writes it.

Confirmed persistence behavior

• It has a generated logical identity and a separately unique event identity.
• It can store event type, optional tenant and correlation context, source service, outcome, and processed time.
• No consumer identity field is persisted.
• No tenant query filter is configured.
• No cleanup, retention, or chronology index is configured.
• The unique event identity differs from outbox uniqueness: processed events track inbound duplicate handling, while outbox tracks outbound publication.

Classification

Foundation persisted object; active inbound consumption is Not implemented.

Requires confirmation

Consumer ownership, tenant access, cleanup, retention, failure outcomes, and future use require confirmation.

Related Articles

• Performance database documentation
• Performance technical documentation

See Also

• Performance API documentation
• Performance business documentation

Keywords

• Performance persistence
• Processed Event Storage
• Draft database documentation

Source References

• microservices/src/performance-service/Infrastructure/PerformanceDbContext.cs
• microservices/src/performance-service/Infrastructure/Migrations/PerformanceDbContextModelSnapshot.cs

Revision Information

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