The Notifications engine currently includes an optional deduplication feature which should guarantee our tenants that each event UUID they provide will be processed exactly once within a 24 hours window. Because of a bug, this feature does not work as initially intended and the deduplication happens over 15 days instead of 24 hours.

We'll fix this issue by splitting the internal and external UUIDs into two different columns in the "event" DB table. UUIDs provided by the tenants will be considered external and will remain optional. Each event will also have its own internal UUID which will always be generated by the Notifications engine.

Acceptance criteria:

• A new "external_id" column is added to the "event" DB table and to the corresponding JPA entity in the Java code.
• The "external_id" column is included in relevant indexes to avoid increasing the response time of the Event Log API.
• If a tenant provides an event UUID through Kafka or the gateway, that value will be stored in the "external_id" column.
• If a tenant does not provide an event UUID, the "external_id" column should contain the internal UUID generated by the engine.
• In all cases, the current "id" column from the "event" DB table should now contain the internal UUID generated by the engine. This column was and will continue to be the primary key of the "event" table.
• In the Notifications REST API, all endpoints that relied on an event ID in their input or ouput are unchanged from an API user perspective. However, they internally rely on the "external_id" column instead of the previous "id" column.
• In the Notifications REST API, if one external UUID identifies several events and the API endpoint should only return one result, only the newest event is returned.
• The "external_id" column and the logic that sets its value are introduced 15 days before the REST API changes to avoid a DB data migration.
• IQE tests should produce events with AND without an external UUID to validate all scenarios.