|API||TOTAL TIME||DATABASE CALL||% TIME CAN BE OPTIMISED USING SOLR|
|PCP||2192 ms||662 ms||30%|
|Allergy||3758 ms||475 ms||12%|
|API||BEFORE CF||AFTER CF||% IMPROVEMENT|
|PCP||2192 ms||14 ms||197%|
|Allergy||3758 ms||16 ms||233%|
So far all good, but how to configure cloudfront to achieve such results? Below are the steps which can help anyone to configure cloudfront with existing APIs.
Assuming cloudfront is deployed, it’s time to configure behaviours for caching. I am using above example to configure two APIs /search/pcp and /search/allergy to cache the content based on our needs. Here are the steps for same –
Once distribution is ready, you can copy the cloudfront URL and hit the API. Note down the response time. Now hit the same API again and compare the response time. You will see a big difference in the response time which means caching is working. Follow the above steps for adding multiple behaviours.
While implementing one of the challenges was that we needed to cache the response only when certain request parameter value is available. In our case our backend was sometimes hitting our own database or hitting third party depending on request parameter value. Whenever we are hitting third party API we don’t want to cache the result. We have handled this using max-age=1 parameter in API response, so whenever cloudfront finds max-age=1 it caches for 1 second and overrides default settings. Now backend has control on what to cache and when.
One of the requirements was to update the cache whenever backend database is updated, so we wrote AWS Lambda function to invalidate specific cache entries using cloudfront invalidate API. We exposed this lambda function using AWS API gateway so that our backend can call the APi and invalidate the specific cache entries based on which db values are updated. I will cover this in our upcoming blogs.
The new architecture turned the response time down to less than half of original resulting in faster responses which in turn made the end user delighted. All this was done without having to change any aspects of the core application or any downtime for the application.
In the end the customer was happy to see savings for time as well as cost.