Order pricing is recalculated in Finance

[jbogard]

In the Finance service, the OrderSubmittedHandler, the implementation calculates a new total for the order by re-retrieving the product pricing information. This implies the customer could be charged for a different price than they original saw.

Consider having the original service pass through the "quote price" or "display price" so that the handler uses what price it showed to the user instead of re-grabbing it.

This was brought up as a question in the BuildStuffLT course.

[mauroservienti]

@jbogard thanks for raising this. To some extend this is an unsolvable problem. The only way to guarantee that the Order is created with prices users saw on the website is to send prices from the page to the back-end. It means that back-end systems need to trust what comes in from the page. Users could change the price and back-ends will create an order with something not valid.

The only real way to solve this in a real-life scenario would be:

• at the back-end level track every price change, e.g. by using something similar to event sourcing
• when displaying prices to the user send them prices + for each price a hash corresponding to the price stored in the event stream
• when the page sends back the order, hashes for each information will be sent back and thus we can check that data coming in are exactly what we expect them to be
• in case in the meantime prices changed the system can react accordingly

had a quick chat with @Particular/microservices-workshop-maintainers and, since this seems to be a problem an hypothetical business needs to address, we decided that instead of fixing it in the exercises we could use this problem to raise a discussion with attendees.

@Particular/microservices-workshop-maintainers which is the best way to track this and store it into some documentation for future usage?

/cc @Particular/microservices-workshop-presenters

[dvdstelt]

@mauroservienti Do you think we need to document this?

The easiest would be to ask attendees: "Would this problem be different if you had to solve this in an old, n-tier, monolithic application?"
If the answer is "yes", then you and attendees can have a discussion on what changed and the reason why, within the concepts of the workshop?

I otherwise would not know how to 'store' this. Would that not become a knowledge base with all questions asked? Where every single time we present this, we'd end up with even more questions?

[adamralph]

I believe this is more a talking point than anything else. For example, we can push the creation of an order ID back even further, to the moment when the price needs to be fixed. That could be when the use clicks "add to basket". That could create an order id in which ever service is responsible and then when the price is calculated for charging, that would be done in the context of an order ID. The exercises are always going to be a huge simplification of what a production system would need to do.

[seanfarmar]

I'd say this scenario in real life we will have a price ID associated with the pice the user is shown on the UI and everywhere else so we can validate it?

[adamralph]

I don't think there's necessarily a need to introduce another type of ID. It should still be possible to do this an order ID. The question is, when is the price binding? I.e. at what point can we not change the price any longer? If we ensure that the order ID is created at that moment, then the price of the product can be associated with the order ID. The price could be binding at the moment of placing the order, adding an item to the basket, or even when the search is performed. This is a question for the business stakeholders to answer.

[dvdstelt]

I'd say this scenario in real life we will have a price ID associated

If business rules demand immutable prices from the moment an item is put in the shopping basket, this could be an option.