Should retries and timeouts live in your application or your service mesh?

This article examines the common debate in distributed systems about where resiliency logic like retries and timeouts should reside: in the application or the service mesh. It argues that while platform components (service meshes, API gateways) are effective for generic traffic-level concerns such as connection timeouts and circuit breakers, they lack understanding of business intent. For context-aware decisions, such as idempotent retries in financial transactions, the application must own the logic to ensure correctness. The recommended approach is a hybrid one, using platform resiliency where possible but deferring to the application when business context is critical. The article warns against over-relying on platform-level resiliency without considering the need for application-level business decisions.