> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/cloud-for-dpi/chapter-2/shared-capabilities-can-help-many-services-and-interrupt-many-services.md). # Shared capabilities can help many services, and interrupt many services Public services often use shared capabilities such as identity, notification, payment, data exchange and certificates. These reusable functions can support many public and private services. A shared capability can reduce repeated work and give services a common way to connect. It can also become a common failure point. If a shared identity service is unavailable, several otherwise healthy services may lose their route to users at the same time. If a certificate service fails, connections that depend on it may stop even though their applications and data remain available.
Two separate service environments each contain an application and persistent data. Both use defined shared dependencies for identity, certificates and private integration. Separate environments limit direct reachability, while shared dependencies can create common failure domains unless independent paths and recovery arrangements exist. Recovery needs both the service-specific records and the dependencies required for the service to work.

Figure 6. Separate service environments limit direct exposure, while shared dependencies can still interrupt more than one service.

The diagram shows two separate services with their own applications and persistent data. They share identity, certificates and a private integration route. Separating the services limits direct exposure between them, yet a failure in a shared dependency can still affect both. This is not an argument against sharing. It is a reason to understand what is shared, who operates it and how dependent services recover. A shared platform or DPI Building Block needs a clear promise to its users. Service teams need to know what it provides, how they learn about an incident and what recovery outcome they can expect. The shared operator needs to know which public services depend on it and what a disruption means for them. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/cloud-for-dpi/chapter-2/shared-capabilities-can-help-many-services-and-interrupt-many-services.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.