Page Comparison

...

Phase 2 implementation plan

TBDThe 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:

1. Modules that publish events and have their own database (e.g. mod-feesfines). Publishing stays in the same module, but Transactional Outbox pattern needs to be implemented. 
2. Modules that publish events and don't have their own database (e.g. mod-circulation). Publishing of these events has to be moved to corresponding storage modules in order to have an ability to implement Transactional Outbox pattern.
3. Log events - these modules can fall into either category 1 or 2, but it should be discussed separately whether they should also implement Transactional Outbox. The only functionality that can suffer from these messages not being delivered is Circulation Log.

Event types that need to be published in mod-circulation-storage instead of mod-circulation:
ITEM_CHECKED_OUT
ITEM_CHECKED_IN
ITEM_DECLARED_LOST
ITEM_AGED_TO_LOST
ITEM_CLAIMED_RETURNED
LOAN_DUE_DATE_CHANGED
LOAN_CLOSED

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

Pattern implementation:

• Create a table message_outbox with fields: id, kafka_topic, payload, status

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.

Technical details and examples

...