How to handle unsent data in microservices

Viewed 26

I have two services A and B. A receives a request, does some processing and sends the processed data to B.

What should I do with the data in the following scenario:

  1. A receives data.
  2. Processes it successfully.
  3. Crashes before sending the data to B.
  4. Comes back online.
1 Answers

I would either use some sort of persistent log to handle the communication between the micro-services (e.g. Kafka) or some sort of retry mechanism.

In either case, the data that A received and processed must not disappear until the entire chain of execution completes successfully or, at the very least, until A has successfully completed its work and passed its payload to the next service. And this payload must exist until the next service processes it, and so on.

Generally, the steps should continue as follows:

  1. A comes back online and sees that there is work to be done: the one that it processed at step #2 (since it's processing is not yet done as far as the overall system is concerned). Unless there are some weird side-effects, it shouldn't matter that it processes it again.

  2. The data is sent to B (although this step should, conceptually, be part of "processing" the data).

If A crashes again then it probably means that the data it processes matches nicely with a bug in A and the whole chain of starting up, reprocessing and crashing will continue for ever. This is a Denial of Service, malicious or not, and you should have some procedure in place to handle it, perhaps you don't reprocess the same data more than a given number of times and log this to be analyzed with top priority.

Related