Welcome to our code-along!
If you are a developer, and want to learn more about micro-services – you should definitely participate in our code-along this spring. We will publish three challenges related to micro-services in April and then gather together with Chris Richardson at a microservice meetup the 6/5 to discuss different ways to solve the challenges and learn from each other.
The challenges will be published on the 2/4, 16/4 and 23/4 in Citerus blog and on our LinkedIn page.
Challenge 1 – Webshop
You are a part of a small back end team at a company which sells terrific 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 mean knowing your customer and keeping track of risk scores. They are measured by the amount of payments that comes in on time and the loss of revenue that occurs when the customers commit fraud.
The web shop is built on a micro-service structure and the company have organized 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 lifted 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 stands up and 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:
One of the services within the cluster 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 the service must first ask another service whether or not the customer is valid for purchase.
The other service 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!
