It's always exciting to start a new project: new challenges, new ideas and the future looks promising. You’re building your content model, adding new content types, functionality, validations — and maybe even implementing some apps or UI extensions using the power of Contentful´s extensibility.

Everything seems to be going fine but, one day, you realize that your content model is getting bigger and bigger and … bigger. Now the time required to maintain and manage your content is overwhelming. Then you have new teams that need to work with Contentful and you need to introduce another level of governance. At this point, it’s clear that your current setup doesn’t work on such a big scale. You need to reconceptualize your model and rebuild your delivery.

This is a familiar story to a lot of us. The good news: this scenario can be avoided.

Think about scaling and future digital strategies at the very beginning of your project. Establishing a multi-space architecture from the start can set you up for long-term success, even if it takes some initial planning.

The possibilities of horizontal scaling

Some time ago, most projects used a single space per project. When the projects grew, the team running them extended the capabilities of that single space. We call this vertical scaling: increased performance so that the space could hold more content types, roles, entries, and new features.

But just like in software architecture, we have multiple options for scaling. With horizontal scaling, teams might divide their project by market, channel or business units across different spaces. This is often an effective solution for current and future needs.

Vertical and horizontal scaling offer different architectures: the first gives you one, big monospace that rules all possible scenarios; the second gives you several spaces, and each space is dedicated to a specific context. 

Spaces divided by business units

Multiple spaces can power multiple business units. Each business unit can be different and independent from another one. At the same time, each business unit might have some organization-wide content and components. Global spaces can be organization-wide, and they are responsible for all content shared across all business units. Each business unit has a small space. This division gives strict governance, independence and flexibility in using content from the global space or changing content in its own business unit. 

Spaces divided by region

In this example, spaces are divided by different regions. If you have different markets that have some similarities and some regional differences, you can have a global space used by all markets and individual spaces per market, which fetch content from the global space. Regional editorial teams can change this content and add their own regional content. The advantage of this use case is pretty straightforward. Using this multispace pattern provides regional units with some autonomy while supplying them with global content.

Space by experience

Another option is to divide your spaces into different spaces for different digital experiences. When you have experiences like campaigns and loyalty programs organized by various teams, multi-space architecture will let you easily create new campaigns for different markets and different channels. Reference spaces can act as blueprints for your campaigns, so every new campaign will go live quickly and without additional complexity or time spent on creation of the content model or thinking of content strategy.  

Microservices architecture

Microservices architecture — assembling a series of services rather than using a single, all-in-one tool — offers many advantages.

It can offer you autonomy and better productivity, because it allows you to build independent, cross-functional teams that solve specific business problems. Even if you are working on a big project, you can still work independently, test everything without involving other parties of the project and deploy only your piece of the project.

That means you’re focused on business needs. Teams can focus on building business functionality rather than writing a glue code. That makes everything easier to build, maintain, test, and deploy.

You can seamlessly scale. Because the project is divided into many different pieces, you don’t need to completely rebuild your system when you scale it — just add the changes to specific parts of your project. You don’t need to have all of the answers up front, because you can always add and substitute services as you go. That minimizes your tech debt and gives you the flexibility you need to keep up.

Everyone wants to use microservice architecture right now, and often it’s the best solution. However, before you go down the path of assembling your services, you need to consider your specific use case. Study your required attributes, build concrete scenarios and weigh each decision so that you can make a fully-informed decision. Your decisions impact the company’s entire workflow and development process. Your editorial and development teams work with this architecture every day. So what would your space architecture look like?

Applied example of multi-space, microservice architecture 

Okay, those were theoretical examples of multi-space architecture. Let's look at a real example that comes from one of our customers. The customer is a global automotive company. 

What’s the use case? 

Let´s scope the customer's use case. Their general requirements were:

• Works on the global market (multiregion)

• Has strong governance and approval processes

• The architecture must be omnichannel, independent from the delivery channel 

• The architecture must be easily scalable (easy to start a new market)

• The architecture must support multiple projects

• Should be able to work with first- and third-party integrations like translations services or asset management systems. 

This list represents a generalization of the primary requirements for the project. We’re not going into detail here, but topics like delivery time and editorial workflow were all extensively discussed.

Diagram of multi-space, multiservices architecture solution

This diagram depicts the space and services architecture that we developed. The diagram might be a bit overwhelming at first, but we’ll review it step by step and explain each decision that was made. 

We divided the architecture into three primary sections in this diagram: customer, third-parties and the content platform (Contentful). We’ll look at the content platform first. 

Content platform: Synching shared and individual spaces

As the content platform, Contentful accounted for all content-related needs of the customer. We provided for organization-wide content with shared spaces. Each shared space was dedicated to a specific topic shared by all of the individual spaces, such as FAQs, microcopy and local information. This prevented duplicative content and copy and pasting tasks.

We then dedicated individual spaces to individual projects. This organization allowed for a strong governance structure. 

To manage all synchronisation and processing of the content between spaces, it's necessary to create an additional services layer where that will happen. To do so, we created another shared space with tags that sync the content across every other space so that the content in shared spaces is current and consistent. To achieve this synchronization it would be possible, just like with other services, to create an app which creates a direct link between content in two spaces. 

Every entry in the shared spaces are describable via tags. Using a cross-space reference app, we added these tags to the application spaces where they’re needed. A microservice can fetch correct data from shared spaces using tags from an application space, which are referenced from shared space with tags. 

Each microservice works only with one application space and connects to all shared spaces. Using cross-space referencing in the application spaces, the editor is able to reference a tag for the legal information or for FAQ at any point in time and at any place where he needs it. 

At the same time each application space using the whole flexibility of Contentful can integrate any kind of third party like Translation Management System, Data Asset Management, A/B Tests, etc. 

Customer: Presentation layers and distribution

Now that all of the content is organized in Contentful spaces, we need to focus on how, on the customer side, we created architecture for the presentation layers and distribution. 

Each individual space has its own service which processes and manipulates the content from the space, caching layer and the front end. The microservice that mapped to the certain space fetches the content from an application space using tags that are referenced, as well as from the shared spaces. The content can then be processed and delivered to the front end.  

Each microservice has its own caching layer, so that updates to application spaces are sent to the microservice using a webhook. The microservice processes that data, builds the page and updates the cache. This keeps content up to date without slowing down users or the high price of data processing. Each microservice can be connected to first- or third-party services, which return data to the microservice or send it directly to a channel. 

As an optional level, you could add an internal caching layer, which orchestrates the data it receives from application or shared spaces. That increases the performance of delivering and processing the content, but it also brings additional costs. You’d have to implement an additional validation process for this, which might be complex. 

The possibilities are endless, and we’re here to help

This multi-space solution has its own advantages and disadvantages. Cross-space referencing is complex. But putting in the additional effort at the beginning will save resources in the future. Updating, scaling and improving is always easier on a stable foundation. It also means that your spaces and services are easier to maintain along the way.

Multi-space architecture can solve any number of equally complicated challenges. It’s a great option whenever you have multiple markets, different business units, or different digital units. Just make sure that you think twice and weigh all your requirements before designing your architecture. 

If you're interested in improving your Contentful knowledge and ensuring that you get the most effective Contentful-based solutions, don't hesitate to contact us in the services team. 

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.