...
Use copies of data to make decisions
In order for it This option has the most potential design variations. It might involve in-memory caching or persistent storage of the copied data and it may involve using messaging infrastructure or periodic requests.
Irrespective of the design variations, in order for this option to be acceptable, a variety of stakeholders within the community would need to accept some tolerance for decisions being made with stale information. When I've talked to with folks about this previously, they have been uncomfortable with doing this (see above).
Characteristics
- Requires no downstream requests for fetching data during check out process
- Increases the potential for stale data to be used for decisions
- State changes still require a downstream request (and the requisite proxying overhead)
- Is contrary to constraints that may still be present in FOLIOstill be present in FOLIO
- Requires less / no (depending upon variations chosen) downstream requests for fetching data during check out process
- Introduces complexity of either caching or processing messages and persistent storage into mod-circulation
- Introduces May introduces a dependency on a database from for mod-circulation on a database
- Introduces May introduces a dependency for mod-circulation on messages produced by other modules
- State changes still require a downstream request (and the requisite proxying overheadMay introduce the need for a system user for mod-circulation (to populate / update the cache)
Variations
The characteristics of this approach varies more based upon some design decisions we make. A couple of the significant ones are outlined below.
...
| Periodic HTTP requests | Messages consumed from Kafka | ||
|---|---|---|---|
| Freshness | Dependent upon frequency of periodic refresh. Likely to be lead to data being stale for longer than with messaging | Dependent upon message processing latency | |
| Access requirements | Needs a system user or module permissions granting to a timer endpoint | Needs access to Kafka topics for every record type (assuming record snapshot based messages as used with mod-search) | |
| Initial population / manual state refresh | Requires requests to fetch all records for for all cached records types | Either requires reprocessing of persistent topic (not currently allowed by FOLIO standards) or custom process (similar to mod-search re-index process) | |
| Load on other modules during synchronisation | Could be significant. Dependent upon number of record types and quantity of records | Potentially none with persistent topics (not currently allowed by FOLIO standards) | Freshness measurement
Combine the business logic and storage modules together
...