If you are a developer, and want to learn more about microservices – you should definitely participate in our code-along this fall. We will publish three challenges related to microservices in November and then gather together at a microservice meetup the 4/12 to discuss different ways to solve the challenges and learn from each other.

The challenges will be published on the 6/11, 13/11 and 20/11 in Citerus blog and on our LinkedIn page.

You are a part of a small back end team at a company which sells squeaky toys for dogs through a web shop. The company is organized around two major business areas. One business area is focused on the order flow, which means the whole sales process, taking orders and follow up on settlements to make sure that customers have paid or not. They are measured by the volume of purchases made and tries to maximize sales. 

The other part of the business manages risk, which means knowing your customer and keeping track of risk scores. A risk score is measured by the amount of payments made on time and the loss of revenue that occurs when the customers commit fraud. 

The web shop is built with a microservice structure and the company organize their technical department to mimic the business; one team who builds the OrderService and one team that builds the RiskService

One day, both of the teams are invited to a meeting where the product people raised an interesting question. 

“We have seen some inconsistencies. It looks like some customers are denied purchases because they have a low risk score even though they do not have any active orders”

The developers start to dig into the code and one of them says:

“Hang on, what happens if one of the services fails to perform their part of the task? If the RiskService updates the risk score for the customer and then the OrderService fails to place the order, shouldn’t we revert what we have done in the RiskService?”

“But where and how do we do that.. ?”

This is the current situation:

The OrderService is responsible for handling orders and persisting the order to a database. To complete an order we must reserve credit for the customer. This means that first the OrderService must ask the RiskService whether or not the customer is valid for purchase. 

The RiskService will respond with either an OK or not okay, and update it’s own database with the customer’s risk score. If the order fails in any way, no information is to be persisted in either database. Same goes for the risk score. If the risk score fails in any way no information is to be persisted in either database. This means that either both services succeeds with their part of the task, or both needs to be reverted to their previous state. 

How would you as a developer solve the communication between these services and the transactions to the databases? Should there be a rollback, and in that case, where would you place it? Should the responsibility lie within the GUI? And how do we communicate to the user that something went wrong?

Take a moment to reflect on how this could be done and please share your findings in the thread below. We encourage you to throw some code on the problem and share the result by posting a link to your github page, but it is not a requirement. Let’s start with sharing our ideas and to reason about them!

Skriv en kommentar