In a microservice environment there are two services: Service A and Service B.

Service A manages an entity called x which has one to many relationship with service B's entity called y

When a network request hits to Service A to delete a specific x, Service A makes an internal network request to service B to validate whether specific x being used with any y item.

In a microservice environment, is there a better and more efficient way to handle this kind of request and validation among two services?

Also these options already came to table, however not optimal.

  1. Managing a cache on Service A about y isn't viable.
  2. Managing a key/property on each x about whether it's being used or not, was also considered. However there's a development overhead of migrating all the old data with new property.
  3. Let the front-end (webapp) directly calls Service B's validation before hitting to delete. However there's a possibility to have a false positive with the timing.

2 Answers 2


If Peter's approach is not viable for you, an alternative:

  • Mark service A's x as DeletePending
  • Send message to service B
  • Service B checks its ys and either:
    • acknowledges with a DeleteApproved message or
    • refuses with a DeleteRefused message
  • Service A receives a message:
    • DeleteApproved --> delete the object
    • DeleteRejected --> set x back to Alive status

BTW: if you have such a tight coupling between services, check your boundaries. Probably A and B should not be separate services in the first place.

  • 2
    +1 for domain boundary. In general when the question is just 'cascading delete', a message (usually async) is sent to a message queue that other services can pick up and process orphaned data related to the entity. If I saw this kind of bidirectional coupling I would definitely reevaluate the design.
    – c_maker
    Commented Jul 1, 2020 at 10:59
  • Isn't this creating an bad practice which Service A should keep an open connection with the front-end's (webapp) request until it receives a message from an sync message queue? Only light here is to look for ack (e.g: amqp) from Service B if the validation is correct.
    – inckka
    Commented Jul 1, 2020 at 11:32
  • @inckka No, basically this is the request-response pattern. The charming thing is, that if service B is temporarily down and in the process of restarting, the only problem for the user is a slight delay.
    – mtj
    Commented Jul 1, 2020 at 12:42

Is the following scenario viable for you?

  • Mark Service A's x entity as SoftDeleting / NotReachable / name it...
    • This should prevent to create new y entities in Service B, so Service B has to check x before allowing creation of y
    • Send a notification about from Service A about x status change
  • Process Service A's status change event in Service B
    • Mark all y entities as SoftDeleted / Inactive / name it...
    • Send a notification from Service B about x related records status change
  • Process Service B's status change event in Service A
    • Mark Service A;s x entity as SoftDeleted* / Inactive / name it...

BTW: Sam Newman's Monolith 2 Microservices book has a dedicated chapter about database migration. Some part of it discussing this topic and fortunately it is available online for free.

  • 1
    This seems to perform a cascading delete, but my reading of the question is that the desire is to refuse the delete if the relationship would be violated. Still, +1 for a well-described possibility.
    – IMSoP
    Commented Jul 1, 2020 at 10:37
  • The main requirement of OP is to validate before delete. As an example, send a message to front-end (webapp) if any ys already using the delete requested x. However +1 for the provided deletion options.
    – inckka
    Commented Jul 1, 2020 at 11:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.