Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
...
The main goal of the issue is to define additional steps to harden the process of loading holdings entities from RM API.
Here are the points to think abouthighlighted in the issue:
1. Create a separate endpoint that gives us the status of the progress of the process.
2. Add retry mechanism in case something fails - at least 3 retries
3. What happens if someone tries to filter resources by tags while the table is being populated/has no entries - we end up making multiple requests to RM API - which can be avoided if we add an updated_at column to our holdings table. Based on when the entry was last updated, we decide whether we want to insert/update the entry or leave it as is - this eliminates the need to truncate the entire holdings table and re-populate increasing performance.
4. What happens if RM API is down? Approach outlined in 3. helps us still retain holdings data albeit stale.
...
Spike results:
Info | ||
---|---|---|
| ||
1. Create a separate endpoint that gives us the status of the progress of the process. |
...
For the implementation of the retry mechanism, we can use the Circuit Breaker pattern existing for Vert.x - https://vertx.io/docs/vertx-circuit-breaker/java/
...