1

I'm very new to micro-services but am trying to learn, so apologies for any ignorance or incorrect information.

I have been looking at event-sourcing architecture for microservices and I have a question when it comes to making a command/post requests and having to wait for their response.

Take this example: I want to create an order but in order to create the order it must be checked to see if the customer has enough money to place it. So I make a post request. This might be straight to the order microservice or might be routed or handled via an api gateway.

From an event sourcing architecture this is my understanding on how it might be created.

  1. Order service would receive order information via a post method and add the order in a pending state.
  2. The order service would publish a order created event.
  3. The pricing service has subscribed to the event. So it will check how much that user/customer has. 3a. If the user has enough money, it will reserve the amount. It will then publish a credit reserved event. 3b. If the user doesnt have enough money it will publish credit exceeded event
  4. The order service will have subscribed to both of these events and will either put the order into placed or deny it. (I dont know exactly what it would do if it is denied but it will not be allowed)

enter image description here (Image is just for reference, this doesnt not imply they world talk directly to each other)

Now a few questions come off of the back of this which I hope someone can please help me.

  1. The user is going to call this to place an order. They are going to want a response when they place this to know if it was placed or not. How do you handle waiting for command operations that you need a response to, and that response relies on waiting on other microservices potentially. If my api is to wait for a change in the order, how is an event picked up via an endpoint?

  2. How does cross microservice validation work. For instance, say before I create the order I want to know if the user it is for actually exists. is this handled by the api gateway which will do initial validation based on the user info?

I understand there is a idea of anonymous microservices (instead of authoritity where each service owns a data set). For instance, the order service would have a copy of all the users and their wallet, so it can check its copy. (same with the users to check it exists). is this the way to go.

Is any of this even correct. Any help would be much appriciated.

Thanks

1 Answer 1

1

The user is going to call this to place an order. They are going to want a response when they place this to know if it was placed or not. How do you handle waiting for command operations that you need a response to, and that response relies on waiting on other microservices potentially.

You have two options.

Firstly you can simply not return a response to the user until all the micro-services have returned. If you think this work won't take that long (ie a few milliseconds) this is an ok strategy. You simply return when the last micro-service has finished its work.

If you are concerned that the HTTP connection will time out before all the work is finished you are better to return immediately saying that the newly created Order resource is in some initial state. The user can then GET the resource later to see if the state has changed. This is known as polling, the user polls the resource until it is in the state they want.

How does cross microservice validation work. For instance, say before I create the order I want to know if the user it is for actually exists. is this handled by the api gateway which will do initial validation based on the user info?

This depends and there is no "right" answer to this. A lot of architectures will do things like user authentication simply once early on (eg check user exists and is authorized for this action), and then all other micro-services wills simply accept that yes that user exists and yes they are allowed do what is being requested.

If the check is more domain specific to one particular micro-service (eg not does this user exist, but something like does this user have a particular balance for this order, or does this user have a particular permission to use this particular micro-service) it is better to do this on the particular micro-service. You want to avoid some thing where one micro-service is checking a very specific permission for another micro-service some where else, since if you change how that permission works on the micro-service it is relevant for, you then have to remember to update the other micro-service that is actually checking the permission.

9
  • Thank you for you reply. I currently have another question to client communication posted on stack overflow and both of your answers are slowing making the picture more clearer. Your answer on the first point seems to help me understand that its not really about getting a response immediately anymore. The response you aim to get in an event based architecture is a created or accepted to signitfty the command has been accepted and a side effect is its going to created that resource in an initial state firing of an event of order created.
    – Matster2
    Jun 5, 2019 at 21:18
  • it seems to be about submitting a command (e.g post of an order) and then polling another resource (which will be given to you via the location header) or will event give you links to other resources to progress a process.
    – Matster2
    Jun 5, 2019 at 21:19
  • Coming from an object oriented mindset and a general case polling is bad, it initially seems quite difficult to accept, but It understanding that these are events and events can take time to process. nothing is instant. Polling is your friend as it will allow you to keep tracks on an event.
    – Matster2
    Jun 5, 2019 at 21:19
  • Well something to keep in mind is that REST is about state transfer. So it doesn't really have a concept of "callbacks" or things to be triggered when something else happens or long running requests. In HTTP (which is a REST protocol) the client says "Hey server, here is the new state of resource X, update your copy of this resource". The response is simply the server either say "Ok I will" or saying "No I won't" for various reasons (4xx or 5xx http responses). There is no concept of "Ok I will try to but it will take a while, hang on while I do some stuff" in HTTP/REST. Jun 6, 2019 at 10:14
  • Even though the server may take a long time to update itself, as far as the client is concerned it just needs to know, relatively quickly, if the server is going to accept this new state for the resource. The client doesn't actually care when the server gets its act together, it just cares if the server will accept this HTTP request (eg PUT) to update the state of a resource, because from the clients point of view it simply needs to care if it needs to do something different to get the server to accept the new state of the resource. Something to keep in mind when designing REST systems Jun 6, 2019 at 10:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.