...

• No changes to the circulation API (the interface must remain the same)
• Only existing infrastructure can be used (I'm including Kafka in this, even though it isn't official yet)

Options

Improve the performance of individual downstream requests

Analyse and try to improve the performance of each downstream request

Characteristics

• Improvements can be undone by changes to downstream modules
• Limited by the constraints of the downstream modules (e.g. the data is currently stored as JSONB)
• Retains the same amount of downstream requests
• Retains the same overhead from Okapi proxying

Make downstream requests concurrently

Make some of the downstream requests

...

in mod-circulation 

Characteristics

• Retains the same amount of downstream requests
• Retains the same overhead from Okapi proxying

Combine downstream requests for related records into a single request

...

It may not make sense to combine all of the record types from a single module. For example, 

Characteristics

• Reduces the amount of individual requests (and hence the Okapi overhead)
• Requires at least one downstream requests per destination module
• Requires at least one database query per downstream module
• Might reduce the load on downstream modules
• Reduction in downstream requests is limited to number of record types within a single module
• Increases the amount of APIs to maintain
• Increases the coupling between modules (by introducing the clients context into the other module)
• Increases the coupling between the record types involved (e.g. it's harder to move record types, changes to them ripple across APIs)

Copy data needed into circulation

Suggest using database for mod-circulation rather than mod-circulation-storage, so to avoid further proxied HTTP requests

...

Consume messages produced by other modules to build views of the data needed to perform a check out.

The biggest challenge with this option is the community's tolerance to using potentially stale data for making decisions.

Characteristics

• Increases the potential for stale data to be used for decisions
• Introduces a dependency on a database from mod-circulation
• Requires no downstream requests for fetching data
• State changes still require a downstream request (and the requisite overhead)

Variations

Store the copied data in mod-circulation-storage

Rather than introducing a database in mod-circulation, use the database that is already used by mod-circulation-storage.

Downstream requests will be needed from mod-circulation to mod-circulation-storage to access the views.

Cache the copied data in each instance of mod-circulation

Rather than introducing a database in mod-circulation, use a volatile cache within each instance of mod-circulation and use downstream requests to populate the cache.

Downstream requests are still needed from mod-circulation to populate the cache. Response times may be less stable when the cache needs to be repopulated.

Combine the business logic and storage modules together

Characteristics

• Storage modules have been used to workaround cyclic dependencies constraints in Okapi, removing them might involve 

Appendices

Definitions

...