Removing all the things - a good time to do things asychronously

Microservices can be great for isolating segments of functionality and data, but there are some situations when all of the various segments need to be prodded.  Deletion of an account or some other core item in the business domain is the classic example and the topic of this post.

Adding or modifying an item is a relatively straightforward process involving a single call to an endpoint.  It either completes successfully or returns a response that provided enough context for the caller to know whether to retry or give up.  This can usually be done synchronously, or in a short enough timeframe for the calling system to establish the state has been saved.

Similarly, a single item or group of items that fall under a common area of functionality can be deleted while the caller is waiting.

I'm going to be lazy and not offer the hypothetical business domain here, but imagine having a dozen microservices, each with their own data store and type of content.  When a request comes in to delete the central item that each of those content types is ultimately associated with we can no longer afford to wait around for each service to check whether it holds anything related and successfully complete the deletion activity.

There isn't a graceful degradation fallback option to respond with when a deletion request times out, so rather than exposing the caller to the possibility of any one of a dozen or more systems hitting a temporary issue we should persist the relevant identifying characteristics of the deletion request and provide a quick to let the caller know that the deletion process has begun.

I'll save the description of possible mechanisms for each sub-system to detect and process any relevant deletion from its data store for another post.

In summary, the distributed nature of data in a microservice architecture should lead us to handling broad actions asynchronously.  Were no longer in a situation of having everything in once central relational database with deletions automatically propagating across tables.  It's part of the trade off of the flexibility to scale and develop new functionality in isolation rather than as a monolith.