Our intent is to use Akamai CDN to cache a whole (static) DXA 1.3 site. We implemented a storage extension that will notify Akamai to flush it's cache when a page is published.

We configured DXA to use CDaaS, which has a time based cache. The DD4T storage layer also has an option to configure a time based cache. And off course the Content Service has the Tridion Object Cache.

Our concern is that when Akamai is notified to flush the cache of a published page, it may cache an stale page when time based caching is used. Obvious solution may be to just disable the CDaaS and DD4T cache, since the origin site is only hit on cache flush.

Has anyone any recommendations for this scenario?

1 Answer 1


It looks like you have 2 different caching expiration strategies in place in the shape of a sandwich:

  1. Event based (Object cache/CCS invalidation notification, which also triggers Akamai to flush)
  2. Time based (DD4T and CDaaS)
  3. Event based (Akamai, but triggered by #1 above)

This is indeed a setup that may cause some staleness issues. If the time-based cache is on the outside, after the event-based expiration, e.g. DD4T polling on a time interval, we will be ok (eventually when the time expires). But in your case, the Akamai part of the sandwich is going to get what it pulled from the middle (as you said yourself).

I wonder, do you really need all those caching layers? What do you gain with each layer? My two cents would be to reduce the polling/expiration interval on the time-based caches down to 1 minute and somehow make Akamai do it's cache refresh with a delay so that it guarantees to hit after that expiration interval. Or peel off some of the caching layers, i.e. turn off the DD4T and CDaaS cache (you can trust Akamai to be reliable, right?).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.