Architecture

The architecture describes the upcoming 3.0 version of Open Content.

For info about older versions, please look at the release documentation at https://wiki.infomaker.se/display/OCS/Open+Content

Scaling Open Content doesn’t mean the same thing for all our customers. Some need a massive index, others have need for a smaller index but lots of traffic or API calls. Regardless of your needs, we are confident we will solve them.

The Open Content stack consists of several parts, all running in the Amazon cloud.

• Load Balancer. The OC stack uses the standard Amazon application load balancers.

• OC API. Is the REST API for queries, read and write, as well as the OC Admin API. Runs in ECS and scales horizontally.

• S3 is the storage where all content items are stored.

• RDS is the database where we store a selection of meta data.

• SolrCloud is the Solr cluster that executes the queries, manages the indexes etc. It's deployed in a EKS cluster, from 1 Solr node and up. We always recommend at least 2 Solr nodes for redundancy.

• Binlog is created by the RDS, and contains all modifications to the OC content.

• Kafka is a streaming platform where we persist all changes to the content item. It also powers the Indexer services. We use the Amazon managed Kafka service.

• The Indexer is the part that extracts the metadata to index and perform the index updates in Solr. The updates are then committed to the index by Solr. The indexer is running in ECS containers and scales horizontally.

• The Notifier is used to create event-driven workflows.

We always recommend a multi-AZ setup for all parts of the stack. That means the Open Content stack is running on multiple datacenters in parallel, enabling high availability.

For Open Content pre 3.0, you'll need to use the master-satellite mechanism (see below) to reach multi-AZ redundancy.

When using Open Content as a creation backend, we always use a Satellite Open Content for the presentation layers. The production and presentation is totally separated each of them can be configured and scaled in the appropriate way.

We recommend to use the Naviga standard configuration for Creation and Presentation. They are both versioned and maintained by Naviga, and are updated when needed to be in sync with the Naviga Creation and Presentation tools.

Master - satellite In complex environments setting up multiple Open Content Satellites might be a suitable way to scale. All content is stored in an Open Content Master setup, and predefined replication rules make sure the correct content is available in each Satellite. This does not require additional storage, they are setup as read-only OC’s, reading the content from the same S3 bucket, saving both time and money. As content can differ each Satellite maintains its own index.