Oskar Dudycz

Pragmatic about programming

What texting your Ex has to do with Event-Driven Design?

2021-01-27 oskar dudyczEvent Sourcing

cover

We sometimes feel melancholic, blue and a bit messy. When we enhance those feelings with “gummy berry juice” then various dubious ideas come to our minds. We grab the phone, we bash out a few brilliant sentences. Bam! Here we go! Usually right after we hit “send” we realise that it was a bad idea. Sometimes we have to wait until morning to understand embarrassment:

  • “Did I really text my ex?!”
  • “Maybe she didn’t read it?”
  • “Maybe I can remove it or at least edit it?“,

Sometimes we are lucky, e.g. we can delete a message on WhatsApp, or edit it on Skype. However, we aren’t sure if the message was read or not. Usually, the best thing to do is apologize or write “I was just kidding!“. You cannot retract a bad situation, but you can try to fix it.

Why am I writing this to you? People often ask me, what will happen in event-driven systems when we publish a wrong event (e.g., missing data, incorrect data, etc.). The recipe is similar to the scenario when texting your ex:

  1. Think upfront: This can save you a lot of trouble and difficulties. Make sure that you correctly understood the logic with the Business, then write tests. Such an approach can protect you from bad consequences.
  2. If you’ve sent the message through Skype, edit it: let’s make it clear, sending a message to an ex after a “gummy berry juice” is never a good idea, even if it seemed like it at the time. However, if the message has not been read yet, there is an escape route: editing it. If we have an event-driven system and send events with a delay (e.g. with the “Outbox Pattern” pattern, read more in my previous post), we can still edit it. If we use, e.g. relational database as storage (e.g. using Marten), we can do it with a migration. Is this “best practice”? Not really, but it works as long as the event wasn’t published yet. Besides, we are not talking here about best practices, but about saving the situation.
  3. If we sent a WhatsApp message, try to delete it: most message buses (e.g. Kafka) allow you to delete messages sent to them. To put it mildly, this is not a recommended solution and has far-reaching consequences. But it can be done. It might not be sufficient, because the message could already be read and deletion won’t help, but it won’t be reread. This is certainly not what I would suggest, but Huston, we have a problem to solve.
  4. Apologise: you can say sorry, you can try to say that someone else got to your phone and did that (“if you were caught red-handed, claim that it is not your hand”). Generally perform the so-called “compensating operation”. It’s just like an invoice. After we’ve issued it, we can’t edit it. We can only correct it. If we transfer too little money to someone, we do not edit the transfer, but we send the second one with the missing amount. Contrary to what “business” used to say, there is always an emergency exit in the process. In an ordinary world, you can always call someone, possibly write an email, to verify they accept your apology. We should do the same in our systems, and we can usually perform a corrective action. This is the only reliable way of making sure that our actions were compensated.

And you know, the basic rule - if you drink, you don’t write!

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 11500 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz

cover

Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.

Some time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.

Many people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.

Many seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?

The end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.

I believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.

After I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?

People usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).

The truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.

Therefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.

Polish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.

Cheers!

Oskar