1

I apologize if this sounds really strange. I am very new to System Design and have just been reading up on Event driven systems. To gain better understanding and to perfect my thought process I decided to try my hand at designing a very simple version of a food ordering/delivery system (like an Uber Eats). What I have explained below is just a subset of the whole system and for just a handful of users.

My original design was to have a message broker like Kafka in the middle and having Order, Payments, Restaurant, Notification microservices all consuming events from it. The Restaurant microservice would be responsible for all restaurant related actions such as accept customer orders, update customer orders, etc. I also wanted this microservice to be in charge of operations such as adding a new restaurant, updating a restaurant, etc. And here's where I am facing a problem.

When the user decides to search for "Mexican", I want this query to be directed to a SEARCH microservice which would query the Restaurant database and return the results. However, since the rest of the microservices use events to communicate with each other, can this SEARCH microservice bypass the Restaurant microservice and directly query the Restaurant database? Would this be an acceptable design? Or should I scrap the message broker design entirely and design something which communicates via REST calls?

1 Answer 1

Reset to default
4

When the user decides to search for "Mexican", I want this query to be directed to a SEARCH microservice which would query the Restaurant database and return the results.

This design goes against the principle of microservices that each service only has access to its own database. If information from other services is needed, then that should be requested through an API or the service needs to mirror the information in its own database.

Using an API to request information from another service does not mean you can't use a message broker as well to pass events where that is more appropriate.

However, if this Search service always needs to get information from the Restaurant service (or it needs a nearly complete duplicate of the Restaurant database) in order to do its job, then your decision to make it a separate service is highly questionable. It looks more like it should actually be part of the Restaurant service.

6
  • Thank for you this! Do you think it would be a better idea to instead break up the Restaurant database into say RESTAURANT_ORDERS and a RESTAURANT where the Restaurant microservice talks to only the former and the SEARCH works with only the latter?
    – Saturnian
    Commented Aug 12, 2020 at 15:24
  • Basically what I'm trying to arrive at is, how do I keep the SEARCH microservice separate from the entire "place-the-order" process while not violating the principles of system design.
    – Saturnian
    Commented Aug 12, 2020 at 15:31
  • @Saturnian, what does the Orders microservice do if it isn't the "place-the-order" process?
    – Bart van Ingen Schenau
    Commented Aug 12, 2020 at 16:14
  • My bad, I meant "process-the-order" workflow - the entire workflow from when the user places the request till it it delivered to him. Orders microservice commits to the orders db.
    – Saturnian
    Commented Aug 12, 2020 at 19:05
  • 1
    @Saturnian, I still think you are trying to create too many services and allocating their responsibilities incorrectly. Try a few scenario's out with pen and paper to see what information needs to be exchanged between services and try to keep that to a minimum.
    – Bart van Ingen Schenau
    Commented Aug 13, 2020 at 5:38

Your Answer

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

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