CODEWITHSUNDEEP
architecturemicroservices
ipalibowhyte
ipalibowhyte

Reputation: 1563

Should business logic be contained in individual services in a micro service ecosystem?

Let's say I just have 2 services Billing and Orders and one API gateway which may fan out requests to these services for billing or creating orders.

Given this new order scenario:

  1. user creates an order (request -> Rest API)
  2. User validation has to be done
  3. Order entity has to be created
  4. Billing entity has to be created
  5. Notification has to be done to notify the user

Where should my application logic sit ? and should the calls to these services be done synchronously (within the rest api) ? or each service should be responsible for calling another ? eg:

New user order request -> Rest API -> calls order service to create order -> (if successful) Rest API -> (if successful) calls the billing service

Or

New user order request -> Rest API -> calls order service to create order -> returns the response. Then order service takes of things from there on asynchronously ?

Thanks!

Upvotes: 2

Views: 3260

Answers (2)

Sean Farmar
Sean Farmar

Reputation: 2283

Your question is not complete, but i can attempt to guess the question from the title...

Each Component should have it's own business logic, components (or microservices) need to be totally autonomous, sharing nothing, no code no data nothing.

Components can raise events (using messaging) to communicate the fact something append.

Make sense?

Here is an example in .net using NServiceBus

Upvotes: 1

enzian
enzian

Reputation: 771

New user order request -> Rest API -> calls order service to create order -> returns the response. Then order service takes of things from there on asynchronously?

Doing something asynchronously that do not have to be processed synchronously is always a good idea! However it's not always possible. If for example you have to return a billing id along with the response from the order service - that has to be a synchronous usecase.

New user order request -> Rest API -> calls order service to create order -> (if successful) Rest API -> (if successful) calls the billing service

Your thing you call Rest API in this description is actually a business service (Create order, then - if successfull - create billing information - is business logic). Your gateways should be very stupid and I advise you NOT to write them yourself! There is plenty of gateway solution out there!

Assuming the gateway now talks to the order (and only the order) service, you need some way of letting the billing service know, that it needs to create billing information for this order! I assume from your question that this does not necessarily need to happen synchronously, so I agree with sean-farmar on this: Use some kind of asynchronous communication to let the billing service know you created a new order. Also consider the billing service to send a message as well, once it finished creating the billing information, so the order service can take this notification and add the ID of the bill to the order. And like this you have completely asynchronously:

  • created billing information
  • linked that information to the order and
  • linked the order to the billing information.

Since this happens asynchronously and your messages could be buffered somehow, one of both services can die without taking the other one down. And once they come to live again - they just need to process outstanding messages!

By the way: Updating just means killing and starting a new version of your service - which means you now have a secure way to update your services without impacting the up-time of your system or your SLA!

Let me know if that was helpful!

Upvotes: 3

Related Questions