I am looking to implement an event driven microservices architecture in my application but I am struggling with the concept of event choreography and UI interaction.
My issue is that I have a membership signup process where a user will enter in a bunch of details into my UI. This will be submitted to a membership service which will process this and then publish an event. It would seem natural for this event to be consumed by a payment service as the next step in the business process is to take payment. The payment service cannot actually process this event fully until it has payment information from the user which need to be entered in the UI.
In the UI, it would be natural that once the user has entered their signup details then UI logic would know to display a payment form and once this is complete to submit the details to the payment service. I am now duplicating the business process in both the front and the back end which feels wrong and the payment service has now been notified twice about this payment.
Does anyone have any advice on the best flow for this scenario. I feel as if I have a piece missing in my understanding here, but I have struggled to find any articles / discussions which deal with this.
Related
Intro
Hey, my question is kind of hard to explain so I apologize in advance.
Question
I'm trying to implement microservices for our ecommerce and I'm having issues on how to respond to a request when the actual logic and data needs to be determined by other ( 2-3 ) services.
In order to make it easier to understand, I'll give an example.
Lets say User A is trying to buy a product. after clicking on "check out" button these steps should happen.
Flow
Request comes in:
Ecommerce service:
Check if product has enough quantity in inventory.
Publish an event indicating a new order has been created. order:created
Anti Fraud service:
Receives order:created and checks whether the user is a fraud or not
Publishes an event indicating the check was successful. check:succeed
Payment Service:
Receives check:succeed and creates a url to the gateway.
Sends the gateway url to the user. (( this is where the question arises ))
Since all of these steps are asynchronous, how do I respond to the request?
Possible Solution
After the user has requested to checkout, the ecommerce service creates an order and responds immediately with the orderId of newly created order, on client-side the user has to request periodically and check whether the status of order is PENDING PAYMENT, in order to achieve this, the payment service needs to publish payment:created after the order has been approved by the system and then ecommerce service can update the order.
My solution works, but I'm really new to microservices and I want to ask from experts like you on how to implement this in a better way.
I really appreciate if you read this far, Thank you for your time.
your flow is a synchronous process. you need a result from previous step so it has to go step by step.
point of system view:
what matters here is: "how to handle steps?". which reminds me SAGA design pattern (specially when you need a rollback handling) but in general there are two types (choreography and orchestration). The choreography describes the interactions between multiple services, where as orchestration represents control from one party's perspective.
for simplicity you can implement the command pattern or use EAI(Enterprise Application Integration) tools like Apache camel to handle message between endpoints according to the flow.
if you have a lots of visitors it's also better to use a queue between endpoints whether with an orchestrator or without.
point of user view:
when a user click to checkout their cart. they don't expect many of steps or to do more than just wait. as keeping the connection open for response is not a good idea maybe a loader and a periodically ajax call behind it is quite enough while there are other solutions like push notification (then you can consider on fire and forget mechanism).
Your workflow for handling a request as it is defined is totally synchronous. Each step depends on the previous step, and cannot start until it finishes. However, second step does not seem to need data from the first step, so actually they could be executed in parallel.
so, what can be done is start both of them:
Check if product has enough quantity in inventory.
Checks whether the user is a fraud or not
then
wait for response and if both are ok, then creates a url to the gateway. and sends it to the user.
You can create a camel route or any other tool that implements EIP to achieve the functionality
Let’s says Checkout has the following services:
Order service , creates order and collects shipping , payment and place an order and manages the life cycle of an order.
Inventory service, provides availability of products.
Shipping service , provides delivery options and costs
Customer profile service, provides customer information.
Credit service, authorization of payment
Reservation service doing the reservation
Here is the flow of order creation :
Order is created, users provides shipping address, shipping options are calculated, payment is collected and order is placed and confirmation shown to user.
Many of retailers checkout are sync and order service orchestrating.
Let’s say if we are using event source , CQRS and event store , order service creates an order event and persists in event store , publish the domain event and all other services subscribed to event store as they need to update the delivery options , shipping cost , payment for to complete an order and using CQRS to inform user the status on each step for him to review.
I am trying to understand :
how complex the checkout application would be with all domain events of checkout like, adding shipping address, reservation, delivery option selection, adding payment and completing the order?
Would it be quicker than sync operation of order service orchestrating the checkout request ?
Would be eventual consistency in case of failure? How to handle evertual consistency ?
Well we can use Event sourcing and CQRS for check out process. Like you said you would be raising events and subscribed services will react to that. How complex or easy is not the question , is it worth it in your case ? Event Sourcing and CQRS is complex pattern with many benefits but you need to implement it right way.
For eventual consistency you may have to rely on Saga Pattern where in case of failure you will have to raise compensating action for roll back.
Been moving into some task oriented UI as a part of my CQRS implementation.
The problem is I have come across the need to update additional properties in my UI as a result of a change made by an initial command sent from the same UI.
My case is different but here's an example...
eg. CommandA Add item to cart resulted in the following events (which all need to be reflected on the UI)
change to store inventory
add item to shopping cart
change total with sales tax
What's the best way to handle this without baking my business logic into my UI?
return a list of resulting events that were performed as a result to the initial command?
return a DTO that reflects changes
other ideas?
I haven't completed it yet, but my idea is to use a Hub from the SignalR framework and subscribe to events and act on them. As long as you can correlate user guids with the connected user guids in SignalR, you can send updates to the correct client and even detect if they still are there.
SignalR isn't that mature yet but the tests I have done works pretty good.
I use it with Knockoutjs and I just update my view models and call functions.
Do those events really need to be reflected in the UI? Consider Amazon, who display "you just added foo to your cart", but don't show any of those other details. That might save you from the problem by redefining it away.
Otherwise, why are you afraid of business logic in the "UI" - specifically, why not include some components from the service that owns each part of that system in your client, and give them the responsibility of doing whatever local updates are appropriate?
In other words, having part of the logic from your sales tax service running in the UI is fine. You (obviously) don't trust it with the billing calculations for tax, but you can totally trust it to do the right thing for the client.
The other advantage of that model is that you get instant feedback for the user, or at least the option of showing instant feedback, without baking more business process knowledge into the client.
For example, recalculating shipping takes time to do - if your client shows a spinner over that, something needs to know to trigger that showing up, right?
If your UI knows that, it has embedded business process around the process. On the other hand, if you have code that is part of the "shipping" service, you can change what response occurs in the client by changing only the one service...
i have integrated a 3rd party payment gateway into magento. It handels a successful transaction or a failed transaction perfectly.
But what if when the user is at the payment gateway page and it times out or when at the payment gateway page the user closes the page and returns back to the site later or user simply hits the back button,
how do i cancel the order then?
Should i use some observer to do this?
If so could you suggest to which events do i need to fire the observer?
the issue i am facing is that when a user is redirected to a payment gateway and he/she hits the back button and comes back to the site, the order is still created, which ideally should have been canceled.
Thanks.
Your validation methods should not be session aware and should process any feedback (and validate before you process) in any case. You also need a monitoring service that times out orders without a response after some time if you need them to be disabled in timely fashion.
However if user hits back button there is really nothing you can do as the feedback from payment gateway never gets sent on user action. I know some payment gateways issue automatic post from the server no matter what you have to investigate if this can be also possible with your payment gateway.
I am building an MVC application (using the Zend Framework).
When users first register, the applicaiton sends them an email. My question is, where should I trigger this email from? The model or the controller? My thoughts are as follows:
In some ways, the model makes sense, since sending a registration email is part of my business logic. Users must click the link in the mail to validate their email address.
But by putting it in the model, I am 'encumbering' the model. The model's registerUser action is then only useful within the context of an application that needs emails sent for every registration.
Instead, by triggering the email from within the controller, my controller would be a litter 'fatter', but my model a little more 'fine grained'.
I have written an email service which actually configures and sends the email, and I think this is a good design decision. I am really just asking where I should be calling this service from.
Your thoughts are most appreciated!
According to Zend Framework's definition of MVC, you should put send the email from the controller:
Controllers...decide which view to display based on the user's request.
Models, on the other hand, contain:
...basic functionality behind a set of abstractions.
An email may be considered a "view" in that it displays information to the user. It is the controller's job to activate this "view."
In my opinion, I would want this in the model, as I would consider this an assumed process of the create user method, rather than any specific interaction with the user making the request.
In other words, since I would always want this email sent, regardless of the source of the request, I would identify this as a natural byproduct of the create user action, similar to a record being saved in a database.
You might want to look into using something like NServiceBus to queue messages to be sent to your Email Service.
This way you can have NServiceBus subscribe to an event that occurs and omit any manual firing of the email service etc.
Ultimately you want a failsafe way of ensuring your messages get to the intended people. This kind of framework will greatly help you ensure that this happens.
Alternatively you could store the emails to be sent inside your database and have your email service check the database queue every x minutes for new emails to send and omit the need for triggering the email sending.
Again, doing it this way will ensure at the least that the emails get sent. Should the network go down or some other disruption occur during the sending of each email you can simply leave them in the queue until the network comes back up.