Hi, 

Cache invalidation for something like this seems overkill if you ask me. I say this because there can be a number of factors where you may want to remove your cached navigation and rebuild it. 

• Page is moved 
• URL segment changes 
• Page is deleted 
• Page is updated

All of these actions have events you can hook into but you would need to then have logic to determine if the given content item is even a part of the cached nvaigation before you invalidate the cache. 

It doesn't seem worth it at all, and from experience if you are to apply heavy logic off the back of event triggers, it can have an adverse affect on the user experience as it can potentially lock the UI. 

I'd suggest just using object caching, and let it expire naturally after a period of time if the cache is relatively short lived.

Thanks,

Paul

You can use Episerver's ISynchronizedObjectInstanceCache https://world.episerver.com/documentation/developer-guides/CMS/caching/Object-caching/ to create a cache of any .NET object that you want to invalidate around any CMS dependancy so that when a CMS item gets changed it invalidtes the cache. This could be on a configuration item for the menus or the pages themselves depending on how you have built the menu. This is full built around scalable solutions and the DXP and works very well, I have used it to cache all the ViewModels for Blocks/Pages to supercharge performance. Example of some using code https://world.episerver.com/forum/developer-forum/-Episerver-75-CMS/Thread-Container/2016/8/isynchronizedobjectinstancecache-load-balancing-issues/ here. 

Hi Deepa

First of all, if you create menu items from regular Episerver content (pages or blocks), you will not hit the database on every request. It will use cached content as soon as the content has been once loaded from database.

But if you have some reasons to cache your custom objects, and have them cleared when Episerver content is changed, have a look at this blog post (by yours truly).