The Runnerly app is a typical web app that interacts with a database and a few backend services. And building it as a monolithic application is the way to go for the first few iterations.

In this chapter, we've demonstrated how the monolith could be gradually split into microservices, and how tools such as Celery can help in that process. Each background process that can be split in an independent Celery task is a potential microservice.

We've also looked at Swagger, which is a great tool to help define APIs between microservices.

This splitting process should be conservative and progressive because it’s quite easy to end up with a system where the overhead for building and maintaining microservices outweighs the benefits to splitting those things out.

If you like software architecture, the last version of the app is pretty appealing. It offers a lot of options for deploying and scaling Runnerly.

However, we've moved from a single application to many applications that need to interact with each other. Every link in the preceding diagram can be a weak point for your application. What happens, for instance, if Redis goes down? Or if there's a network split between the Data Service and the Strava Service in the middle of a process?

The same question goes for every new network link that was added in our architecture. We need to be resilient when something goes wrong. We need to know where we're at and what to do when a service that was out gets back online.

All of these problems are addressed in the next chapter.