# Handling synchronous cross-service dependencies when subgraphs ARE the backend services

**URL:** <https://community.apollographql.com/t/handling-synchronous-cross-service-dependencies-when-subgraphs-are-the-backend-services/10236>\
**Category:** API Design, Strategy & Governance\
**Created:** [November 1, 2026, 2:25pm UTC](https://community.apollographql.com/t/handling-synchronous-cross-service-dependencies-when-subgraphs-are-the-backend-services/10236 "2026-11-01T14:25:46Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![deebugger](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/deebugger/32/5919_2.png) [@deebugger](https://community.apollographql.com/u/deebugger)\
**Post date:** [November 1, 2026, 2:25pm UTC](https://community.apollographql.com/t/handling-synchronous-cross-service-dependencies-when-subgraphs-are-the-backend-services/10236/1 "2026-11-01T14:25:47Z")

</div>

Hi everyone,

In our architecture, subgraphs are not thin adapter layers over separate domain microservices. Instead, the subgraph servers are our actual domain services (handling database logic, domain rules, and business workflows directly).

We’ve run into a situation where a mutation in Subgraph A requires a synchronous check or validation against a domain state owned exclusively by Subgraph B before it can commit or abort.

Because our services are built as GraphQL-first subgraphs, we are debating the cleanest way to bridge this:

1. Mounting internal HTTP/REST endpoints alongside `/graphql`: Adding non-GraphQL internal routes (e.g., `/internal/validate`) on Subgraph B that Subgraph A calls directly over the cluster network. (Team pushback: feels like breaking our GraphQL-only standard and introduces point-to-point service coupling).

2. Direct GraphQL queries between subgraphs: Having Subgraph A send a GraphQL query directly to Subgraph B. (Concerns: redundant query parsing, complex `errors` envelope handling, circuit breaker blind spots).

3. Asynchronous Saga/Events: Emitting an event and moving to eventual consistency. (Concerns: high overhead for operations where the client expects an immediate pass/fail).

For teams where the subgraph is the service, how do you handle synchronous cross-domain mutations without compromising service autonomy?

I’m waiting to get some feedback from this community - cheers!