...
Phase 1 implementation plan
See the feature Jira Legacy server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-4328
For each of the affected modules:
...
Phase 2 implementation plan
See the feature Jira Legacy server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key UXPROD-4381
The effort required to implement Transactional Outbox pattern varies depending on the module and the event type. They can be split into 3 categories based on the level of complexity:
...
Event types that need to be published from mod-feesfines (the same module that is publishing them now to PubSub):
FEE_FINE_BALANCE_CHANGED
LOAN_RELATED_FEE_FINE_CLOSED
Module name | Has a DB |
---|---|
mod-circulation-storage | Y |
mod-circulation | N |
mod-patron-blocks | Y |
mod-feesfines | Y |
mod-remote-storage | Y |
mod-audit | Y |
Pattern implementation:
- Create a table message_outbox with fields: id, kafka_topic, payload, status
- Every process that wants to publish messages should create a new entry in the message_outbox table with status NEW. It should be part of the same transaction as the change that the message is related to (e.g. loan update during check-out).
- Create a timed process that will check for the new entries in the message_outbox table and publish messages if needed.
Note. Additional complication comes from the fact that Transactional Outbox pattern doesn't guarantee that the message will be sent exactly once (could be more than once). This means that we need to introduce some unique identifier and check it on the consumer side.
...