Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

Due to redis lock being held for a long time, which made the forex api-calls synchronous, we had to re-frame the way how things were being operated for forex rates fetch, The changes includes:

1. Acquiring redis lock, just before api-call and releasing it once data is written on redis.
2. Always responding back with stale-data and operating everything (redis-write, update, api call) on background thread.
3. Throwing error, if api_keys are missing in configs, whenever call is being made.
4. Greater log coverage.

Additional Changes

• This PR modifies the API contract
• This PR modifies the database schema
• This PR modifies application configuration/environment variables

Motivation and Context

How did you test it?

1. Testing for first call when there is no data present in cache as well as redis:
   

curl --location 'http://127.0.0.1:8080/forex/rates' \
--header 'api-key: xxxxxxx' \
--data ''

2. Testing for the case, when data is present in cache and/or redis:

3. For cases when data is expired in cache, it will provide us with the stale data and a background thread will be spun which will update the data on cache as well as redis.

Full response:

{
    "data": {
        "base_currency": "USD",
        "conversion": {
            "TWD": {
                "to_factor": "32.939501",
                "from_factor": "0.0303586869758591667797274767"
            },
           ......
            "MOP": {
                "to_factor": "8.011576",
                "from_factor": "0.1248193863479545098242842607"
            }
        }
    },
    "timestamp": 1735904610
}

Checklist

• I formatted the code cargo +nightly fmt --all
• I addressed lints thrown by cargo clippy
• I reviewed the submitted code
• I added unit tests for my changes where possible