...

• Business logic must use the most current state for decisions (this is what the SME have told me in the past conversations I've had and is supported in technical documentation)
• Business logic and storage are split in two separate modules (in order to support independent substitution)
• All integration between modules is done via HTTP APIs (proxied via Okapi)
• All data is stored within PostgreSQL
• A record oriented design with a single system of record for each record type (business logic / storage separation not-withstanding)

Some of these have changed since this early development e.g. the use of Kafka for integration.

Some may need to change for the options below As these weren't explicitly documented at the time, it is difficult to know if they have changed over time.

There are counter examples which would suggest that they may have changed:

• some more recent modules (e.g. mod-courses, mod-data-export-spring) have both business logic and persistent storage within the same module
• some modules (e.g. mod-search, mod-inventory, mod-data-export-spring) use Kafka (rather than HTTP) for communication
• some modules (e.g. mod-search) use Elastic Search for persistent storage (though not the book of record)

I don't know if these constitute a change in policy or specific exceptions.

Some of the options presented below contradict these constraints and would need them to change to be tolerable and coherent within FOLIO's architecture.

Expectations

A checkout (including the staff member scanning the item barcode) must complete within 1 second (from the documented /wiki/spaces/DQA/pages/2658550). It is stated that this includes the time for a person to scan the item barcode.

...

Analysis

Limitations of Analysis

Whilst Thanks to the PTF team we have overall performance data for (an approximation of) the whole check out process, .

However we only have a single detailed sample of the downstream requests from the check out API. That sample is not representative of the range of response times likely present in a whole performance test run.

...

• Only involves changes to mod-circulation
• Increases the complexity of the code in mod-circulation
• Not all requests can be made concurrently (some are based upon prior requests or decisions that cannot be made up front)
• Is likely limited by how well other modules / database can handle concurrent requests
• Retains the same overall load on the system as before (although it may be compressed in time)
• Retains the same amount of downstream requests
• Retains the same overhead from Okapi proxying

Combine multiple downstream requests for related records into a single request

Introduces context-specific APIs that are intended for specific use. At most, this can only be applied to the requests made to the same module.

...

• Removes all downstream for record types within the circulation domain e.g. loans, requests, loan policies etc (include state changes e.g. creating a loan, fulfilling a request)
• Removes the distinction between business logic and storage representations of those records types
• Allows for state changes within the circulation domain to be done within a database transaction
• Is contrary to constraints that may still be present in FOLIO
• Storage modules have been used to workaround cyclic dependencies constraints in Okapi, removing them might involve changing other modules to avoid this in other ways

Recommendations

Before reading this, please take some time to consider the options presented above and consider them for yourself (alongside any others you may think of) in order to reduce the potential for my recommendations to sway your opinion.

There are lots of unknowns with all of these options. It is difficult to predict how long they will take or how much improvement will be achieved. Please keep that in mind when considering these recommendations.

Earliest reasonable improvement

Combining multiple downstream requests into a single request is likely to provide some improvement. This work is familiar to developers and can be achieved without contradicting broader architectural concerns (beyond the coupling considerations).

As there is already ongoing development work that explores this, we can use that to gauge the effectiveness of this approach before committing to a direction for continued work.

Most significant improvement

Copying data into circulation has the most potential for improvement as it removes the need for many of the downstream requests entirely.

However, this work requires adoption of techniques and technologies unfamiliar to most developers in FOLIO and will need agreement from other stakeholders (e.g. SME's, TC) before proceeding.

Appendices

Definitions

...