Resilience keeps an application useful when services or dependencies fail. Instead of propagating an Agenda service failure, the Frontend can serve cached data while other application areas remain available. section 2.4.2
Build resilience into service boundaries with practical failure-handling mechanisms:
- Use cached responses so user-facing components can continue operating with limited functionality. section 2.4.2
- Run at least two replicas for services where minimizing downtime matters, especially user-facing components. section 2.6
- Add automatic retries for service-to-service requests, using exponential backoff to avoid overloading failing services and networks. section 7.1.2
- Treat downstream contracts, networks, and services as failure points rather than assuming they always behave as expected. section 7.1.2
Keeping the Conference application available
Scale the Agenda deployment to zero replicas. The container stops answering requests, but the Frontend displays cached agenda entries, while users can still access other services such as the Call for Proposals form. The Back Office identifies the Agenda service as unhealthy. section 2.4.2
kubectl scale --replicas=0 deployments/conference-agenda-service-deployment
Use the Kubernetes scaling command to deliberately remove Agenda replicas and observe the application's fallback behavior. section 2.4.2
