AEM Dispatcher — Create the Perfect Caching Architecture | AEM Community Blog Seeding

[#1]

AEM Dispatcher — Create the Perfect Caching Architecture by Achim Koch

Abstract

A few thoughts on why developers should think about caching as a vital part of application design…

AEM is a powerful and versatile framework for building content applications. It can be used to power everything from static websites over customer portals to single page applications.

Usually, AEM is used on platforms for massive audiences. It’s no secret that web applications perform best and scale when content is cached. AEM is no exception. That’s what the AEM Dispatcher is used for nowadays: Caching — despite its name.

(The last time I saw a Dispatcher setup to dispatch requests to multiple Publish servers was over ten years ago)

Given the broad variety of different applications, there obviously is no single “best practice”, and there are no one-size-fits all configurations.

But sadly, the dispatcher- and caching configuration is often left as an afterthought to system administrators.

Caching must be an integral part of the application design not an afterthought

If you follow me, you know: Caching must be an integral part of the application design, and thus must be defined by the AEM architect and considered by the developers when implementing the components.

Again, there is no one-size-fits all. But there are a small number of principles that help in designing the AEM application for optimal caching. To choose the proper mix of strategies, however, we need to know a little bit about our application. We need to:

know which content is public / protected / restricted / private
know which content can be shared
identify content dependencies and invalidation domains
know the request distribution pattern
understand the business requirements
Let’s dive into the topics…

Content privacy
We distinguish between several types of content:

Public — Each user can access to the content. No login required.

Segmented — Users don’t have to log in, but they are identified as a certain type of user when entering the page (eg. healthcare “professional” or “patient”, “EU Customer” or “US customer”, etc...)

Restricted — The user must log in first. They can then access certain types of content that has been shared with groups they are member of.

Protected — All users can access all content after they have logged into the system. This is a special form of “restricted”: Restricted to all users.

Private — User-specific content, such as login data, profile data, private messages, etc.

Read Full Blog

AEM Dispatcher — Create the Perfect Caching Architecture

Q&A

Please use this thread to ask the related questions.