Which design patter should I use

Although I'm familiar with the design patterns described in The Gang of Four, on an enterprise level there will be a lot of patterns that I've never heard of. Hopefully there is one that will inspire a solution to the problem I'm facing at work:

I have three applications that are working together. Let's call them ApplA, ApplB, and ApplC. They share some domain models, e.g. the class MyEntity

 public class MyEntity
 {
    public Guid ID {get;set;}
    public string Name {get;set;}
    //other properties 
 }

It is possible for the user to rename such an object using ApplA. When that happens, action should take place in both ApplB and ApplC. This is enabled by using queuing (Kafka, but the choice of queuing system probably doesn't matter). Following the happy path, both applications pick up the message from the queue, and perform their respective actions.

However, the alternative path is that either ApplB or ApplC fails when processing a message from the queue. Say application ApplB fails, then ApplC should not perform its action, or alternatively undo it's action. Is there any pattern / guidance on how to address such issues.