From Cache Invalidation to Continuous Materialization
Caching has traditionally been used in web systems like AEM Dispatcher to address performance, scalability, and availability challenges. However, it introduces significant complexity related to content freshness, performance after cache purge, and debugging across multiple caching layers.
Continuous Materialisation offers an alternative by pre-generating and delivering content directly at the edge, eliminating the need for cache management.
wolf
Why would the Dispatcher / CDN not store assets or representations of the fragments? Nothing in „pull model” prevents that.
Marek Czajkowski
If CDN is in front of edge layer then assets can be cached but the whole idea is not to have to cache. If there are things that change rerly like some icons or images you can still put CDN in front and use it to cache them, just skip CDN for the content that changes a lot
Ramon
How does the new architecture handle updates to "subparts" (content elements included etc) - i.e. conflict than the old way doesn't know about what a change impacted
Marek Czajkowski
I dont know if I get it right but if you mean like header or footer they can be processed as fragments and put on the web server. The pages simply includes them via SSI but what is included is ready static files. Whenever this fragment changes a new version is replacing the fragment and all the pages are including a new version as soon as the fragment is placed on webserver
alexandereggers
The push model feels like it may risk a lot of unnecessary computation for content nobody is asking for. Is this something you might do on a per-page basis or even more granularly?
Michael
I guess this could be useful if your page takes a long time to render. I would argue however that in such case fixing and optimising the said rendering should be the correct solution.
wolf
You are assuming the data can be reliably pulled, a previous adaptTo() had a presentation on places where that is not true (e.g. China)
alexandereggers
I guess my assumption is that pull will always be more reliably correct about when information is needed. My concern is less about correctness and more about efficient use of resources.
Michael
You can always make an edge case to everything. China will be an issue for both solutions.
Gatar
Continuous materialization means that content is prepared up front. That means that with each independent element (degree of freedom) from which the content is built, the number of possible combinations grows exponentially. How do you handle that?
Michal
You materialize what can be materialized. It is not always static content, it may be stateful edge API with a local database
Edgar
How to manage this solution when the changed data cames from a content fragment? Is it able to recognize also the change when it is not on the page / component directly?
Marek Czajkowski
It's all about how the integration on source system is implemented. On AEM if you are able to catch the fact that content fragments has changed you can push this information for processing
Simon
Do you still use Cache-Control und ETag headers? Or how do the cache layers decide to retrieve a new version of a page?
wolf
You ultimately have to, as CDN is never the last layer of cache to control
Simon
That's why I asked
Michal
We do have Envoy Gateway at each of the edge locations, we can control headers there. Together with rate limits, redirects etc.