All content is indexed in the Elasticsearch content index and each node in the cluster maintains its own in-memory cache of content objects and surrounding metadata to minimize and eliminate trips to the database. Each node in the cluster communicates cache and index changes to other nodes in the cluster via TCP or UDP. All nodes in a dotCMS cluster need to share a common database (for content) and file system (for files and assets).
When a request for a CMS asset comes in, the CMSFilter in dotCMS decides if this request is for a file or a rendered page. If the request is for a file, permissions are checked and then the file is served statically, via the AssetServlet. If the request is for a rendered page, dotCMS checks permissions and published status first. Once those checks are made, the system looks to see if the page is in the page cache. If the page is in the page cache, it will be served statically which is 5 to 10 times faster than serving a rendered page. If the page is not in the page cache, the page will be rendered on the fly. The page rendering process calls the API layer via Velocity ViewTools. The API then call ElasticSearch and the object cache layer before hitting the database. When the dotCMS serves a page that is fully loaded in the object cache there are no database hits required, even though that page is rendered dynamically. This means that once the cache is loaded, dotCMS does not require database queries to display rendered pages, even though every content object is checked for permissions and every content query is dynamic (e.g. show the latest published News Articles tagged "show on front page" sorted by publish date).