...
- adoption of techniques (e.g. synchronising copied data, messaging, caching) and technologies (e.g. Kafka) unfamiliar to most developers in FOLIO
- agreement from many stakeholders (e.g. SME's, TC) that it is acceptable to use potentially inconsistent or out of date information for making decisions
Suggested Plan
- Continue with work to improve the slowest response time HTTP requests in the analysis:
- Fetching automated patron blocks (the Vega team have already done some work to improve this)
- Fetching manual patron blocks (Holly is raising an issue for this soon)
- Fetching an item by barcode (the Core Platform team have already done work to improve this)
- Updating an item (Julian has raised an issue for this)
- Work with the RA SIG and POs to decide whether some tolerance for potentially inconsistent / out of date information may be used during check out
- Work with Technical Council and Tech Leads on designs for the use potentially inconsistent data e.g. caching or persistent derived data
- Begin to introduce derived data during check out
- Starting with introducing an expiry cache for a single record type that is populated during a check out, as this approach likely has a shorter lead time to benefits at the trade off of less consistent performance
- Iterating through remaining record types in a priority based upon feedback from the RA SIG and the relative response times for requests (likely isn't appropriate for large data sets like instances or items)
- Investigate adopting Kafka for updating the cache (as this could lead to reduced delay to become consistent)
- Investigate adopting persistent derived data rather than caching (as this removes the need for per-module instance caching, can spread rather than duplicate the effort of achieving consistency, and allow for more use of derived and more efficient structures)
Appendices
Definitions
Phrase | Definition |
---|---|
Downstream request | A request made by a module (via Okapi) in order to fulfil the original incoming request e.g. mod-circulation makes a request to mod-users to fetch patron information |
Response time | The time taken from the client making the request to receiving a response |
Derived data | "A dataset that is created from some other data through a repeatable process. Usually use to speed up a particular kind of read access to the data. Indexes, caches, and materialized views are examples of derived data" ([1], pg. 554) |
Eventual consistency | Copies or derivations of Derived data can be outdated with respect to the it source(s). It is intended that this inconsistency is temporary, however this deliberately vague and there is no limit on on how far behind ([1] pg. 162) a copy might get or how long it will take for it to become consistent again. The term originates from database replication and is often used in event sourcing or event driven architecture architectures. |
Requests made during a typical check out
...
Intent | Endpoint | Destination Module | Sample Response Time (ms) | Sample Response Time of Token Check (ms) |
---|---|---|---|---|
Initial request | 99 | |||
Fetch user (making the request) | GET /users/{id} | mod-users | 6 | |
Fetch permissions | GET /perms/users?query=userId=={id} | mod-permissions | 16 | |
Generate downstream token | 12 | |||
Fetch user (patron) by barcode | GET /users?query=barcode=={userBarcode} | mod-users | 13 | 86 |
Fetch manual blocks | GET /manualblocks?query=userId=={userId} | mod-feesfines | 133 | 7 |
Fetch automated blocks | GET /automated-patron-blocks/{userId} | mod-patron-blocks | 546* | 27 |
Fetch item by barcode | GET /item-storage/items?query=barcode=={itemBarcode} | mod-inventory-storage | 163** | 10 |
Fetch holdings | GET /holdings-storage/holdings/{id} | mod-inventory-storage | 57 | 9 |
Fetch instance | GET /instance-storage/instances/{id} | mod-inventory-storage | 22 | 7 |
Fetch location | GET /locations/{id} | mod-inventory-storage | 9 | 13 |
Fetch library | GET /location/units/libraries/{id} | mod-inventory-storage | 10 | 7 |
Fetch campus | GET /location/units/campuses/{id} | mod-inventory-storage | 10 | 7 |
Fetch institution | GET /location/units/institutions/{id} | mod-inventory-storage | 11 | 7 |
Fetch service point | GET /service-points/{id} | mod-inventory-storage | 9 | 8 |
Fetch material type | GET /material-types/{id} | mod-inventory-storage | 8 | 7 |
Fetch loan type | GET /loan-types/{id} | mod-inventory-storage | 22 | 8 |
Fetch existing loans | GET /loan-storage/loans?query=status.name=="Open" and itemId=={itemId} | mod-circulation-storage | 9 | 17 |
Fetch requests | GET /request-storage/requests?query=itemId=={itemId} and status==("Open - Not yet filled" or "Open - Awaiting pickup" or "Open - In transit" or "Open - Awaiting delivery") sortBy position/sort.ascending | mod-circulation-storage | 10 | 9 |
Fetch circulation rules | GET /circulation/rules | mod-circulation-storage | 18 | 18 |
Fetch loan policy | GET /loan-policy-storage/loan-policies/{id} | mod-circulation-storage | 10 | 8 |
Fetch tenant locale | GET /configurations/entries?query=module=="ORG" and configName=="localeSettings" | mod-configuration | 16 | 10 |
Fetch overdue fines policies | GET /overdue-fines-policies/{id} | mod-feesfines | 19 | 8 |
Fetch lost item fees policies | GET /lost-item-fees-policies/{id} | mod-feesfines | 11 | 10 |
Fetch opening days | GET /calendar/periods/7068e104-aa14-4f30-a8bf-71f71cc15e07/calculateopening?requestedDate={{dueDate}} | mod-calendar | 12 | 8 |
Fetch user (patron) groups | GET /groups?query=id=={groupId} | mod-users | 17 | 7 |
Update item status | PUT /item-storage/items/{id} | mod-inventory-storage | 194 | 13 |
Create loan | POST /loan-storage/loan | mod-circulation-storage | 16 | 8 |
Update patron action session | POST /patron-action-session-storage/patron-action-sessions | mod-circulation-storage | 10 | 7 |
Fetch user | GET /users/{id} | mod-users | 6 | 15 |
Fetch patron notice policy | GET /patron-notice-policy-storage/patron-notice-policies/1a821238-0cd9-48d9-a71a-057d33df0154 | mod-circulation-storage | 6 | 7 |
* The Vega team have already done some work to improve this
...
References
[1] Martin Kleppman: Designing Data-Intensive Applications. O'Reilly, 2017. ISBN: 978-1-449-37332-0
...