In the previous chapter, the Runnerly monolithic app was split into several microservices, and more network interactions between the different parts were consequently added.

When a user looks at the main web view, the application needs to fetch the list of runs and races from the database and the races. The network calls that are triggered by that request are synchronous because we want to display the results immediately.

On the other hand, the Celery workers are doing their duty in the background, and they receive their order via a Redis broker asynchronously.

There are also cases where a mix of synchronous and asynchronous calls are useful. For instance, letting the user pick a new training plan can trigger the creation of a series of new runs in the background while displaying some info about the plan itself.

In future versions of Runnerly, we could also have more service-to-service interactions, where an event in a service triggers a series of reactions in other services. Having the ability to loosely couple different parts of the system via some asynchronous messaging is quite useful to prevent interdependencies.

In any case, the bottom line is that we need to interact with other services through the network synchronously and asynchronously. These interactions need to be efficient, and when something goes wrong, we need to have a plan.

The other problem introduced by adding more network connections is testing: how do we test in isolation a microservice that needs to call other microservices to function?

In this chapter, we'll explain:

• How a service can call another service in a synchronous way, and make these calls as efficient as possible
• How a service can make asynchronous calls and communicate with other services via events
• Some techniques to test services that have network dependencies