Architecture

dotCMS large clustered, horizontally scalable CMS with separate installation in multiple tiers.

10,000 Foot View: Enterprise Deployment

Below is a high level example of a large enterprise deployment that separates an example DotCMS installation into 5 tiers.

Horizontally Scalable Environment with Cluster Elastic Architecture

Content, Sites and even OSGi plugins can be migrated across environments using Push Publishing and or via Bundles.  dotCMS has been designed to allow you to separate your web sites and web applications into n-tiers so you can design a deployment process that meets your requirements.  

Clustered, Horizontally Scalable Environment

dotCMS has been designed from the ground up to scale horizontally.

scalable-cms-environment

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).

dotCMS Individual Node Architecture

Serve your content in a performant and reliable manner regardless of end point or device.

Single Node view of dotCMS Request Response with external elasticsearch

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).