> ## Content Index
> Fetch the complete content index at: https://insights.growthlogic.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# Designing Client Connections with Fault Tolerance
- URL: https://insights.growthlogic.net/designing-client-connections-with-fault-tolerance/
- Published: 2026-08-06T17:59:51.000Z
- Updated: 2026-09-15T16:22:56.000Z
- Author: Aleksandr Jones

Customers visiting your website are generally unforgiving. If they encounter slow response times, prominent errors, or incorrect results, their confidence quickly erodes.

All cloud-hosted systems are vulnerable to system faults, whether caused by network outages, system errors, or other factors. Thus, architecting for the cloud means building resilience from day one.

Our first line of defense is to design client connections that are less brittle. One component that addresses this directly is [Polly, an open-source library](https://thepollyproject.org/?ref=insights.growthlogic.net). The name "Polly" alludes to the cliché of parrots mimicking cries.

Let's start with a plain HTTP client call to an external REST API. Our system needs to call another system's API.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/09/image-1.png)

In this hypothetical scenario, our server receives a request, but our client doesn't receive a response due to connection issues. It's normal for clients to throw an error and report it to the customer. However, if this happens too often, we risk alienating customers.

Instead of immediately reporting failure, we'll try a different approach. If it fails, we'll have our client retry the call. This is exactly where Polly excels. Let's update our flow.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/09/image-2.png)

We now have a retry strategy in place. When an HTTP client call fails, Polly waits and then retries the same call until it succeeds. Polly is powerful and flexible.

Polly lets us control multiple factors: how long to wait before the next retry, how many times to retry, etc. We can add circuit breakers to give up trying altogether and fallback behaviors (aka Plan "B").

Already this is much more resilient. Let's add some more real-world context.

REST APIs are usually secured with short-term credentials, often called access tokens or access keys. We now need our HTTP client to retrieve an access token.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/09/image-3.png)

Access tokens are typically valid for a limited time. After they expire, APIs return an "unauthorized" response. 

Currently, Polly only retries API calls that originally caused an exception. Retrying a call with a stale access token is like retrying an expired credit card.

Thus, let's modify our setup so that Polly handles obtaining our refresh access token.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/09/image-4.png)

When Polly encounters networking issues, it retries the calls. When Polly fails because of an expired access token, it gets a new token and retries the same API call. Polly is now the central point for managing resilience.

Next, we'll add one more layer of resilience. This addition may appear somewhat heavy-handed at first, so let me explain the reasoning.

In an [earlier article](https://insights.growthlogic.net/approaching-basic-scalability-problems-using-asynchronous-communication/), we explored message queuing. We're now applying the same design pattern to our *own* client system – not the remote system, mind you.

![](https://storage.ghost.io/c/a1/f9/a1f9e93d-97a6-4902-a912-72ae1fb6eca2/content/images/2026/09/image-51.png)

API calls are now queued for execution, and a separate asynchronous process makes the actual call. Call failures occur within the worker process and on a different time frame. Our actual customers are now insulated.

This is enterprise-grade resilience. Thanks to message queuing, Polly handles retries and unauthorized access failures in isolation. That said, we do need to rethink our user experience.

We can't tell our users that their data was saved – because it wasn't. We've placed a request in a message queue and are waiting for our async process to save the records. How to handle this effectively is a whole other topic.

Anyhow, we're now firmly on the path to eventual consistency – a much more mature approach to distributed computing. We now deliver better customer experiences and more resilient system flows, both of which support stronger outcomes.