This chapter gives a high level architectural overview of ACE Core, a headless content management system.

ACE architecture

architecture

ACE consists of a large number of components, which can be grouped into two categories: internal components that should only be accessed by other components of ACE, and web services which are the way you interface with ACE.

Internal components:

  • Couchbase (3rd party)
  • ZooKeeper (3rd party)
  • Kafka (3rd party)
  • Kafka Connect
  • Indexer
  • Solr cloud (3rd party)
  • Amazon S3 (3rd party)

Web services:

  • Content Service
  • Search Service
  • Taxonomy Service
  • File Service
  • File Delivery Dervice
  • Image Service

Http caching:

It is possible and sometimes desirable to place http caches in front of the ACE web services to make the system even more performant. The primary services to be used with http caching is hinted in the diagram above.

Depending on the application of ACE many times it is also beneficial to use a proxy service for the whole system to make services available under a common domain name and port number. This proxy may also make use of a http cache.

Optimally, clients of ACE, like a web server hosting a web site on top of ACE should also use another layer of http caching configured to suit its specific use of ACE to increase the performance further.

Couchbase

At the center of ACE is Couchbase, a highly scalable document database. While this is a very important component, it should only be accessed through the services that make up ACE's API, or tools supplied as part of ACE. The document structure in Couchbase is not documented and may change in incompatible ways between releases (but ACE will always maintain backwards compatibility with existing data).

ZooKeeper

Kafka and SolrCloud uses ZooKeeper to maintain some of their internal state.

Kafka

To keep all parts of the system informed when content is created, modified or deleted, ACE uses the Apache Kafka platform. Kafka Connector records all changes in Kafka, and then Kafka distributes them to clients which need to be informed of updates.

Kafka Connect

Kafka Connect is the component that is responsible for listening to changes in the database, and record corresponding change events on a Kafka topic.

SolrCloud

Search in ACE is managed using Apache Solr, an open source enterprise search platform. Content is indexed in Solr by the Indexer component, which also depends on Kafka and the Content Service.

LDAP

LDAP is one of the available authentication backends.

Amazon S3

Binary files are stored in Amazon S3 (or a compatible service). Needs to be available to the File-Service.

Indexer (internal)

The Indexer component is responsible for listening to changes published on the Kafka queue, and update the internal Solr collection accordingly.

Indexer (public)

The Indexer component is responsible for listening to changes published on the Kafka queue, and update the public Solr collection accordingly.

Web Services

Content Service

Access to the data in the system is primarily through the Content Service, which provides a higher level view of content than just documents, and also handles authorization, authentication and data transformation.

Search Service

Searching should be done using the Search Service, which is a wrapper around Solr that adds some additional features, chiefly permission related. It uses Solr and the Content Service.

Taxonomy Service

The Taxonomy Service provides read access to the taxonomies used to categorize content.

File Service

The file service is used to store binary data. It is meant for use from internal applications, and relies for security on the difficulty of guessing random UUIDs. It relies on Amazon S3, or a compatible service.

File Delivery Service

The file delivery service is used to fetch files that are associated with content. Unlike the file service, it enforces permissions based on the content the file is associated with. It relies on the content service and the file service.

Image Service

The image service is used to apply edits to images, and to scale them to a size suitable for the context the image is used in. It relies on the content service and the file service.

Scaling ACE

It is possible to horizontally scale all the ACE services by running multiple instances of the services. None of the ACE services have any persistent state, making it easy to just start up a new instance.

All the 3rd party services also inherently support horizontal scaling. The 3rd party services contain state making them a bit harder to scale as described in their respective documentations.

Docker

The Ace Components are distributed as Docker images and it is advantageous to have all components deployed as Docker images, refer to the Ace Starter Kit for an example.