Cache transaction details instead of the application session
Hello,
is it possible to store temporarily the user session details instead of the application session
In other words: having millions of users asking for eligibility in request 1 then subscribing in request 2
=> request 1 will return a token valid for 5 min, the latter can be used to subscribe in a service.
I am avoiding the check eligibility a second time when subscribing within 5 minutes (OTP lifetime)...
can a cache be used for this purpose as well?
Answer by Dino-at-Google
·
Feb 23 at 10:15 PM
Sure you can use PopulateCache and LookupCache for caching arbitrary data using various keys.
But, you will need a way to distinguish one user from another. Some unique identifier. A Token does that, but if you are caching something BEFORE you grant a token, then you don't have the unique identifier.
Solving your problem the way you've described it may be a bit of a challenge.
One way to do it is to use the "messageid". This is a unique identifier for every message. You could use that a the cachekey in the first request, and then send it back in the response. The require the caller to re-transmit the original messageid in the subsequent request-for-token message. This would allow you to lookup an item in the cache based on the original messageid.
We have worked recently on this type of scenario. In our case the request for a particular user creates a session at backend side. In response header the session id and cookies comes back to the client app and the same is used for the subsequent calls to maintain the session.
Another scenario is there we have used for one of the mobile users. We create a new access token and refresh token with password grant type for the first call. Then for the next calls of that session it uses token generation with refresh token grant type. That ensures the entire process is a session.
Thank you @Dino-at-Google and @Priyadarshi for your reply,
It's good to know that this method can be used to achieve the requirements and even to be the best practice to do that on APIGEE.
Actually, we went over the documentation but it did not answer our technical concerns
Knowing that Cached data is stored in machine memory, so the cache can store data "up to the memory capacity of the virtual machine", which means it's not precisely specified here.
If we have millions of users requesting this API would there be an impact on the environment?
in the documentation, we see that we can have 2.5 million items in each cache:
(Q) When creating a cache in the UI we have a field to set the Expiry date, is it for all the KeyFragments that will be created later on? or it will be considered as the default time for a "keyFragment" if the <ExpirySettings> param is not set?
Thank you,
