Core Idea
Interservice Communication Pattern is a data access strategy in distributed architectures where services obtain data they don’t own by directly requesting it from the owning service at runtime, rather than duplicating the data locally.
Definition
Interservice Communication Pattern is a data access strategy where services obtain data they don’t own by directly requesting it from the owning service at runtime. Services “ask” for data rather than “store” copies of data owned by other bounded contexts, preserving single-source-of-truth semantics while introducing runtime dependencies.
Key Characteristics
- Data ownership enforcement: Each service owns its domain data exclusively; consumers cannot directly access another service’s database
- Request-based access: Consumers make API calls (REST, gRPC, messaging) to data owners, treating the owning service as the authoritative source
- Strong consistency at read time: Data retrieved is current as of the request moment, avoiding stale data issues inherent in replication patterns
- Runtime coupling trade-off: Consumer services depend on owner service availability and response time, creating dynamic coupling that affects reliability and performance
- Network overhead: Every data access incurs network latency, serialization costs, and potential failures
- Scalability implications: Data-owning services become bottlenecks if frequently queried by many consumers
Why It Matters
This pattern is essential for maintaining clear data ownership in distributed architectures—ensuring each domain has a single source of truth. It is most appropriate when strong consistency is required and data changes frequently.
However, runtime dependencies impact availability, latency, and scalability. If the owning service is unavailable, all dependent services fail. High-traffic scenarios can overload data-owning services—necessitating migration to alternatives like Column-Schema-Replication-Pattern or Replicated-Caching-Pattern.
Related Concepts
- Synchronous-Communication (common implementation using request-response APIs)
- Asynchronous-Communication (alternative implementation using message-based requests)
- Bounded-Context (defines data ownership boundaries between services)
- Dynamic-Coupling (runtime dependencies created by interservice calls)
- Availability (affected by dependencies on data-owning services)
- Coupling (parent concept covering all dependency types)
- Software Architecture - The Hard Parts - Ford, Richards, Sadalage & Dehghani - 2022 (primary source material)
- Column-Schema-Replication-Pattern - Alternative pattern duplicating data columns
- Replicated-Caching-Pattern - Alternative using synchronized caches
- Data-Domain-Pattern - Alternative sharing database schemas
- Distributed-Transactions - Complexity introduced when operations span service boundaries
- Service-Granularity - Affects how often interservice communication is needed
Sources
-
Ford, Neal; Richards, Mark; Sadalage, Pramod; Dehghani, Zhamak (2022). Software Architecture: The Hard Parts - Modern Trade-Off Analyses for Distributed Architectures. O’Reilly Media. ISBN: 978-1-492-08689-5. Available: https://www.oreilly.com/library/view/software-architecture-the/9781492086888/
-
Microsoft Learn (2024). “Interservice communication in microservices - Azure Architecture Center.” Available: https://learn.microsoft.com/en-us/azure/architecture/microservices/design/interservice-communication
-
Microsoft Learn (2024). “Data sovereignty per microservice - .NET.” Available: https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/data-sovereignty-per-microservice
-
GeeksforGeeks (2025). “Inter-Service Communication in Microservices - System Design.” Available: https://www.geeksforgeeks.org/system-design/inter-service-communication-in-microservices/
-
ByteByteGo (2024). “Data Sharing Between Microservices.” Available: https://blog.bytebytego.com/p/data-sharing-between-microservices
-
Hohpe, Gregor and Bobby Woolf (2003). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley.
AI Assistance
This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.