150
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications
processed more than once. For instance, if retry logic causes a sender to send exactly the same
message more than once, you need to make sure that it is idempotent.
It is possible to design idempotent messages. For example, you can create an event that says “set the
product price to $25” instead of “add $5 to the product price.” You could safely process the first
message any number of times and the result will be the same. That is not true for the second
message. But even in the first case, you might not want to process the first event, because the system
could also have sent a newer price-change event and you would be overwriting the new price.
Another example might be an order-
completed event that’s propagated to multiple subscribers. The
app has to make sure that order information is updated in other systems only once, even if there are
duplicated message events for the same order-completed event.
It is convenient to have some kind of identity per event so that you can create logic that enforces that
each event is processed only once per receiver.
Some message processing is inherently idempotent. For example, if a system generates image
thumbnails, it might not matter how many times the message about the generated thumbnail is
processed; the outcome is that the thumbnails are generated and they are the same every time. On
the other hand, operations such as calling a payment gateway to charge a credit card may not be
idempotent at all. In these cases, you need to ensure that processing a message multiple times has
the effect that you expect.
Dostları ilə paylaş: