Product ordering
Last updated
Last updated
Ordering service should be created the same way customer service was created in the previous step
Once the service is generated, we can again validate that the generation was successful by deploying it to the local cluster. This time the deployment will be done by using the update command in the CLI, as the local cluster should already be set up from the previous step.
After the CLI process has been successfully completed, we can validate the deployment using the kubectl tool
It should return something like this
All code for product ordering logic can be seen in the pull request above.
Product ordering works in a way where customer creates a new order request by using REST api. Once the order is created, a new order entity is created and order service broadcasts the message about order creation through the RabbitMQ messaging.
This is the first update in which RabbitMQ messaging is used to notify other services of a state change. The event definition can be seen in the service specific constants library.
The event is comprised of
Payload type, which is used for type inferrence when publishing the event
Routing key, a key which determines who will receive the copy of the message
Event version
The default RabbitMQ configuration is using a Fanout exchange. This exchange broadcasts the message to all queues bound to the same routing key.
The order functionality introduced new endpoint which has to be added to the ingress config.
The ingress and service should be deployed locally the same way as in the Customer authentication step.
Once everything is deployed, we can test the newly added API by creating a new order
Once the order is created, we can take the order id, and use it to get the order details
The next step in demo project implementation is order payment reservation.
