search

YugabyteDB-Samples / yugastore-java

An implementation of a sample e-commerce app composed of microservices written in Spring (Java), a UI based on React, and YugabyteDB as the distributed SQL database.
Apache License 2.0
146 stars 66 forks source link

[Question] so does this mean each microservice run their own database with different schema? #3

Open simkimsia opened 5 years ago

simkimsia commented 5 years ago

For example, when the checkout service needs reflect product details such as description, how does it "fetch" this data?

Does it have a duplicate of the production description in its own database? or it fetches it from the product microservice directly? or indirectly via the API gateway?

E,g, I am assuming that checkout microservice is responsible for displaying the checkout list.

image

rkarthik007 commented 5 years ago

It fetches the product data from the product microservice using a REST API. Note that the API gateway is present for end user authentication and security purposes. The microservices themselves are free to talk directly to each other using REST calls.

simkimsia commented 5 years ago

Thanks for reply @rkarthik007

The microservices themselves are free to talk directly to each other using REST calls.

They directly talk with each other without going past the API gateway?

So what does the Order microservice store?

When building a monolithic version, the simplest way is to have a Order, Product, and OrderLineItem table.

What happens is that OrderLineItem has both Order id and Product id.

In the microservice model you have, do you store Product id inside the Order microservice? and do the various microservices access the same database or have their own separate database?

rkarthik007 commented 5 years ago

Sorry for the slow response - @ameyb and @nchandrappa: could you folks chip in? You guys are way more knowledgeable about Spring than me.

nchandrappa commented 5 years ago

They directly talk with each other without going past the API gateway?

API-gateway is used for serving customer/public facing APIs which means the UI App or any other clients that want to make use of the backend services will be served out off of API gateway.

All the backend microservices are aware of each other through eureka service discovery and they don't need to go through the API gateway.

nchandrappa commented 5 years ago

When building a monolithic version, the simplest way is to have a Order, Product, and OrderLineItem table. What happens is that OrderLineItem has both Order id and Product id.

In microservices architecture, domain driven design is widely adopted to identify the bounded context of each microservices. At the end of day, advantages of moving to MS architecture is to enable faster prototyping and each of the microservices can progress at their own speed right.

Following this design principle, we have created Products, checkout, cart microservices and none of them share any state. However each of the them are aware of "api-id" which they use for retrieving the necessary information, this is where magic of service discovery and feign clients come in.

Lets consider the checkout functionality,

UI Checkout Button -> API Gateway -> checkout Microservice ( uses product microservice for Product description, cart microservice to retrieve items in cart )

Table Design: Checkout Microservice -> Products Inventory, orders (order line item) Products Microservice -> Products description Cart Microservice -> cart

Checkout microservice is only responsible for performing transactions on Product Inventory and orders table. @simkimsia