Service communication is the interaction between independently deployable services that request or exchange data. Reliable interactions require more than a stable API contract: failures, retries, dependency versions, configuration, and security boundaries can affect the whole system. section 7.1.2
Common implementation concerns include:
- Add retries inside services with language-specific libraries such as Spring Retry or go-retryablehttp; exponential backoff can reduce overload while a dependency recovers. section 7.1.2
- Recognize that separate retry libraries, framework versions, and configurations make behavior difficult to standardize across services. section 7.1.2
- Move shared interaction behavior into platform capabilities so teams can configure resiliency policies without adding custom dependencies or application code. section 7.3.2
Dapr provides Service Invocation APIs through daprd sidecars. Services call a local API instead of directly calling one another, while platform configuration supplies resiliency policies. The same approach can also expose state management and publish/subscribe through replaceable component implementations. section 7.3.1 section 7.3.2
Conference application
The Conference application uses Dapr service-to-service invocations between the Call for Proposals, Agenda, and Notifications services. Dapr resiliency policies handle their interactions, while PubSub and Statestore components can replace direct Kafka and Redis clients. Adoption remains selective: the Call for Proposals service can retain PostgreSQL where SQL-specific features are required. section 7.3.5
Figure 7.24 Service-to-service interactions can be handled by the daprd sidecar, allowing platform teams to define different resiliency policies.
Shows how daprd sidecars handle service-to-service interactions and let platform teams define different resiliency policies. section 7.3.5
