Edition 0 Updated to asp. Net core 0

if
(itemsToUpdate != 
null
) 
{ 
foreach
(
var
item 
in
itemsToUpdate) 
{ 
if
(item.
UnitPrice
!= newPrice) 
{ 
var
originalPrice = item.
UnitPrice
; 
item.
UnitPrice
= newPrice; 
item.
OldUnitPrice
= originalPrice; 
} 
} 
await _repository.
UpdateBasket
(basket); 
} 
} 
} 
} 

---

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.