The following diagram describes our new application organization. Both the Reports and Strava service get some work from Redis and interact with the Data Service, as shown in the following diagram:

The Data Service is an HTTP API that wraps the database containing all the users and runs data. The dashboard is the frontend that implements the HTML user interface.

Some of the information required by the Celery workers can be passed through the Redis broker, such as the Strava tokens for the Strava service.

For the Reports service, however, it's not practical to send all the info through Redis because the amount of data can be significant. If a runner is doing 30 runs per month, it's simpler to let the Reports service pull them directly from the Data Service.

The Data service view needs to implement the following APIs:

• For the Strava service--a POST endpoint to add runs
• For the Reports service
• A GET endpoint to retrieve a list of user IDs
• A GET endpoint to get a list of runs given a user ID and a month

As you can see, the HTTP API is minimal--we want to expose as few entry points as possible. Although the structure of a run is going to be shared across all services, we need to expose as a few number of fields as possible.

For our service implementation, we will rely on the Open API 2.0 standard.