Improving Our Offline Download Experience

We live in a world of microservices. Microservices help us break up monoliths and make our teams scale but there’s a con; some services might be down when accessed. Yeah, we can have fancy architectures to mitigate that, but ultimately, it happens.

We offer an offline experience for our flagship product (Bloom) and in order to achieve this, we need to save a subset of our customer’s data on their devices. We retrieve the necessary data from our various services.

We went with the optimistic approach where when the service is up everything is fine but when the service is down, the experience suffers.

Flowchart for the old logic

Repeatedly, we noticed that whenever the service didn't return a status code 200, the download exits, and users would complain that it was stuck and we would tell them to hit the refresh button. This isn’t the best approach since we can catch the errors and handle them in the background without interrupting the user experience.

So we came to the conclusion that when the service returns a status code between 400 and 599 we assume the service is going loco and retry it after a while (5–30secs) and hope most times actually it returns a 200.

These are some of the effects we wanted to achieve in no particular order

1. Fetch a particular resource

• If the request succeeds, continue to the next
• If the request fails, sleep for a specified amount of time and repeat step 1 again

2. Configure the options provided like sleep time, no of retries to attempt, etc.

3. Reuse the code for all the resources we need to download to provide the best offline experience.

Flowchart for the improved logic

Here’s the code piece by piece annotated with comments.

Yes, I use a light theme

This approach has significantly improved our user experience.

Thanks for reading, we hope you learned something new. Please drop your feedback in the comment section.