Tweeted twitter.com/StackSoftEng/status/1083740424244736000
2 grammar
source | link

Where should business logic sitssit in microservice architecture?

Still trying to wrap my head around microservice architecture since I'm used to a monolithic approach

Suppose we try to build a extremely simplified Uber booking system, to. To simplify things we let's say we have 3 services and a gateway api for the client: Booking, Drivers, Notification andand we have the following workflow:

When creating new booking:

  1. Check if existing user already have a booking
  2. Get list of available drivers
  3. Send notification to the drivers to pick up the booking
  4. Driver picks up the booking

Let's say all messaging is done through an http call rather than a messaging bus like kafka to keep things simple.

So in this case, I thought that the Booking service can do the checking for existing booking. But then who should be getting the list of available drivers and notification? I'm thinking of doing it on the gateway level but then now logic is kind of splitted insplit into two places:

  • Gateway - get list of available drivers + send notifications
  • Booking - check for existing booking

And I'm pretty sure gateway is not the right place to do it but I feel like if we are doing it in the Booking service, it's becoming tightly coupled?

To make it more complicated, what happens if we have another project that wants to reuse the booking system but with its own business logic on top of it? That's why I thought of doing it in the gateway level so the new project gateway can have its own business logic separate from the existing one..  

Another way of doing it I suppose is to each project have projectsits own booking service that will talk to the core booking service but I'm not sure what's the best approach here :-)

Where should business logic sits in microservice architecture?

Still trying to wrap my head around microservice architecture since I'm used to monolithic approach

Suppose we try to build a extremely simplified Uber booking system, to simplify things we let's say we have 3 services and a gateway api for the client: Booking, Drivers, Notification and we have the following workflow

When creating new booking:

  1. Check if existing user already have a booking
  2. Get list of available drivers
  3. Send notification to the drivers to pick up the booking
  4. Driver picks up the booking

Let's say all messaging is done through http call rather than messaging bus like kafka to keep things simple

So in this case, I thought that Booking service can do the checking for existing booking. But then who should be getting the list of available drivers and notification? I'm thinking of doing it on the gateway level but then now logic is kind of splitted in two places:

  • Gateway - get list of available drivers + send notifications
  • Booking - check for existing booking

And I'm pretty sure gateway is not the right place to do it but I feel like if we are doing it in the Booking service, it's becoming tightly coupled?

To make it more complicated, what happens if we have another project that wants to reuse the booking system but with its own business logic on top of it? That's why I thought of doing it in the gateway level so the new project gateway can have its own business logic separate from the existing one..  

Another way of doing it I suppose is to have projects own booking service that will talk to the core booking service but not sure what's the best approach here :-)

Where should business logic sit in microservice architecture?

Still trying to wrap my head around microservice architecture since I'm used to a monolithic approach

Suppose we try to build a extremely simplified Uber booking system. To simplify things we let's say we have 3 services and a gateway api for the client: Booking, Drivers, Notification and we have the following workflow:

When creating new booking:

  1. Check if existing user already have a booking
  2. Get list of available drivers
  3. Send notification to the drivers to pick up the booking
  4. Driver picks up the booking

Let's say all messaging is done through an http call rather than a messaging bus like kafka to keep things simple.

So in this case, I thought that the Booking service can do the checking for existing booking. But then who should be getting the list of available drivers and notification? I'm thinking of doing it on the gateway level but then now logic is kind of split into two places:

  • Gateway - get list of available drivers + send notifications
  • Booking - check for existing booking

And I'm pretty sure gateway is not the right place to do it but I feel like if we are doing it in the Booking service, it's becoming tightly coupled?

To make it more complicated, what happens if we have another project that wants to reuse the booking system but with its own business logic on top of it? That's why I thought of doing it in the gateway level so the new project gateway can have its own business logic separate from the existing one.

Another way of doing it I suppose is to each project have its own booking service that will talk to the core booking service but I'm not sure what's the best approach here :-)

1
source | link

Where should business logic sits in microservice architecture?

Still trying to wrap my head around microservice architecture since I'm used to monolithic approach

Suppose we try to build a extremely simplified Uber booking system, to simplify things we let's say we have 3 services and a gateway api for the client: Booking, Drivers, Notification and we have the following workflow

When creating new booking:

  1. Check if existing user already have a booking
  2. Get list of available drivers
  3. Send notification to the drivers to pick up the booking
  4. Driver picks up the booking

Let's say all messaging is done through http call rather than messaging bus like kafka to keep things simple

So in this case, I thought that Booking service can do the checking for existing booking. But then who should be getting the list of available drivers and notification? I'm thinking of doing it on the gateway level but then now logic is kind of splitted in two places:

  • Gateway - get list of available drivers + send notifications
  • Booking - check for existing booking

And I'm pretty sure gateway is not the right place to do it but I feel like if we are doing it in the Booking service, it's becoming tightly coupled?

To make it more complicated, what happens if we have another project that wants to reuse the booking system but with its own business logic on top of it? That's why I thought of doing it in the gateway level so the new project gateway can have its own business logic separate from the existing one..

Another way of doing it I suppose is to have projects own booking service that will talk to the core booking service but not sure what's the best approach here :-)