Decoupling an organisation's Content consumption and Content production

[ankit-joinwal]

Background:
A content provider will have two broad domains - content production and content consumption. These domains will typically be implemented by two interfaces - one for consumers and one for producers.

Question:
We want to decouple the content production services from content consumption services in favour of achieving software resiliency. This means we create two unified graphs as opposed to One Graph. The data model will often look same when represented in the two unified graphs. The DGS services on content consumption side will mostly implement Query only. The DGS services on content production side will contain Query and Mutation to serve the interface for content producers.
Any thoughts/feedback on this architecture style based on experiences from Netflix ?

[paulbakker]

I think this depends on many factors. For example:

1. Who are the users of the APIs? Are they separate groups (e.g. internal users vs external users)?
2. Are the backend systems for consuming and producing completely de-coupled?
3. How does authz work for both? Is there a completely different authz story for consumers vs producers? (this goes back to internal/external)
4. Is there any reason to "hide" the producer API for consumers?

Looking at Netflix, there are really two ways to answer this. One scenario is the Studio space - basically, the workflows related to the production of shows. We have many applications in this area, used by a wide variety of users. Just think about all the different roles involved in the production of a big-budget movie.
We have one graph that represents all the data in this space. Some apps produce data in this graph, others consume that data. So looking at this example, we use the one graph pattern, and I think that's most relevant to your question.

Stepping back further, the graphs for the Studio space and the graphs backing the Netflix application that you use as a Netlflix user are separate and serve very different goals. So you could make an argument that the Studio graph is about producing, and the Streaming graph is about consuming. Both graphs are serving a completely different side of the business however, and isn't so much about architecture anymore