So far, we've split out of our monolith everything related to background tasks, and we've added a few HTTP API views for the new microservices to interact with the main application.

Since the new API allows us to add runs, there's another part we can split out of the monolith--the Training feature.

This feature can run on its own as long as it's able to generate new runs. When a user wants to start a new training plan, the main app can interact with the Training microservice and ask it to generate new runs.

Alternatively, the design could be reversed for better data isolation: the Training microservice publishes an API that returns a list of runs with their specific structure, exactly like the Strava API that returns activities. The main Flask app can then convert them into Runnerly runs. The Training plan can work without any specific knowledge about the Runnerly users: it gets asked to generate a plan given a few params.

But doing this new split should happen for a good reason. "Is the code behind the training algorithm CPU consuming?", "Is it growing into a full expert system that's being used by other applications?", "Will the Training feature need other data in the future to work?"

In the same vein, the Race feature could probably be a standalone microservice at some point, since a list of races could be completely independent of the Runnerly database.

The following diagram shows the final Runnerly design, featuring four microservices and the main Flask app. In Chapter 8, ;Deploying on AWS, we'll see how we can even get rid of that main application, turn the Data Service as a full microservice, and build a JavaScript application that integrates everything: