Thanks for the research, in general what was agreed:

1. use existing tables for polines, pieces, titles that will be used by batch job to handle piece statuses instead of creating some additional persistence model

2. batch job should use RMB Timer API and should be located in orders-storage closer to data

3. additional table for storing piece status change history is no required in mod-orders-storage, instead standardized approach with kafka and mod-audit will be used where we will store snapshot's of piece changes

There is more details/benefits for the third option with using mod-audit above:

• asynchronous processing that is more suitable for auditing;

• performance would be better instead of approach with table in mod-orders-storage where we need to get piece from DB and compare statuses and save only in case when statuses not match;

• in case of implementing some mechanism for clearing old audit data it will be easier if all audit data collected in single place;

• it will be possible to implement full audit history for pieces as we did for polines or orders;

• the amount of effort between 2 approaches is almost similar: for case with a new table in mod-orders-storage we need to create table and API in storage(1 story), create API to get history in business module and modify piece service to compare statuses and write to this new table. For kafka/mod-audit approach we need to create table in mod-audit and endpoint for retrieval(1 story), and 1 story for mod-orders-storage to leverage already existing approach with sending audit events and using transactional outbox pattern, all necessary code infrastructure like kafka producers, consumers already implemented in both modules

Closing this story

CC:  

please take look.

, , MODAUD-174 were created as a result of the POC. Updated description for: