This blog post contains ideas for content delivery applications to leverage multiple headless CMS repositories with specific information about stacks (repositories) in the Contentstack SaaS headless CMS, though much of this information may apply to any CMS or other repository.
Along with content type definitions, content entries, and media assets, stacks contain system data such as access tokens and webhook configuration. An organization can implement multiple stacks. A typical approach is to implement one stack for each project, such as each website, but organizations can use stacks in other ways. For example, an organization could implement a stack that contains product information used by multiple product websites that store marketing content in additional stacks.
In some cases, it may be necessary to synchronize content type definitions and system data between stacks. For example, multiple websites can use the same content type definitions, which must appear in each stack. Some organizations may choose to progress content type definitions from one or more development stacks to one or more production stacks, potentially through one or more test stacks. In some cases, content may flow in the opposite direction of content types, from production to test and development stacks. Some organizations may use temporary stacks for non-production environments, such as development and test stacks only during initial site rollout and for significant projects.
Entries in a stack may contain the URLs of entries in other stacks, but not all entries have URLs and entering or even copying URLs and other identifiers from one stack to another is cumbersome. Custom user interfaces can allow CMS users working in one stack to select entries from one or more other stacks.
One potential use of multiple stacks is to separate resources managed by developers from resources managed by CMS users. A solution that manages multiple websites may implement a content delivery pattern that uses entries in one stack to retrieve environment-specific configuration information such as the domain and stack to access for each site and references to additional entries containing content and additional configuration data. Other entries in the same stack could contain values available to all the sites.
Accessing multiple stacks involves managing access credentials for multiple stacks.
Before architecting a solution or selecting a service plan, talk to your CMS vendor about the number of repositories allowed, which could affect how you use them.
Search engines and even individual indexes can aggregate data from multiple stacks. For example, a search index for a website could contain some data from a stack used for site configuration and some data from a stack used for content. See Web Service Brokerage Architecture [for Headless CMS] – Deliverystack.net and Centralizing [Headless] [CMS] Data Access – Deliverystack.net for additional information.
Large organizations may choose to represent themselves as multiple Contentstack organizations, each of which manages separate stacks, possibly sharing a common configuration stack and other stacks for other purposes.
If you have additional perspectives on using multiple headless content management repositories, please comment on this blog post.
Deliverystack.net 
2 thoughts on “Multiple [Headless] [CMS] Repositories”