...
With data size implications, it might be reasonable to create separate tables per each entity type
...
Risk | Description | Probability | Impact | Mitigation | |
|---|---|---|---|---|---|
| 1 | Long period for audit records retention | The number of records could overwhelm the capability of postgres the Postgres database both from a computational point of view and cost | High | High | Introduce separate storage for audit-events |
| 2 | Cascade Updates will create redundant copies in the audit log | The update to holdings causes updates to all related items. Some holdings may contain ~15000 records | High | Medium | Collapse or filter out events that only change parent entity |
| 3 | Some flows could update inventory entities without using the Domain-events mechanism | With different capabilities of the system including UI, data import, bulk edit, etc some of the flows might skip sending Domain events and/or edit entities directly | Low | Medium | List those cases and add domain events to flows that has no this capability |
Questions
[Arch] Acquisition log solution uses a Transactional Outbox pattern to ensure atomicity of
business and audit operation. This is done because this log contains data related to financial
operations. Do we need to use the Transactional Outbox pattern for the Inventory case?We need an outbox pattern if we REALLY need to track those changes
[Arch] Do we use mod-audit or just source module? (acquisition log uses mod-audit module but with specific tables)
Use mod-audit with audit separate table for inventory events
Retention period: is not yet addressed
[Product] There is a library for the comparison of Java objects that outputs the difference between two objects in the following form:
...