149
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications
The event handler needs to verify whether the product exists in any of the basket instances. It also
updates the item price for each related basket line item. Finally, it creates
an alert to be displayed to
the user about the price change, as shown in Figure 6-24.
Figure 6-24. Displaying an item price change in a basket, as communicated by integration events
Idempotency in update message events
An important aspect of update message events is that a failure at any point
in the communication
should cause the message to be retried. Otherwise a background task might try to publish an event
that has already been published, creating a race condition. Make sure that the updates are either
idempotent or that they provide enough information to ensure that you can
detect a duplicate,
discard it, and send back only one response.
As noted earlier, idempotency means that an operation can be performed multiple times without
changing the result. In a messaging environment,
as when communicating events, an event is
idempotent if it can be delivered multiple times without changing the result for the receiver
microservice. This may be necessary because of the nature of the event itself, or because of the way
the system handles the event. Message idempotency is important in any
application that uses
messaging, not just in applications that implement the event bus pattern.
An example of an idempotent operation is a SQL statement that inserts data into a table only if that
data is not already in the table. It does not matter how many times you run that insert SQL statement;
the result will be the same
—
the table will contain that data. Idempotency like this can also be
necessary when dealing with messages if the messages could potentially be sent and therefore
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ş: