Let's say I have an application where I use multiple microservices. Two of them are USERS ( /users ) and CARS ( /cars ).
Given a page called rental history ( /users/{id}/history ) which lists the rented car of the users.
Should I introduce an intermediary microservice RENTAL ( /rental ) which would query the other two microservices for the best architectural design ?
What is the correct design if I wanted to deploy this app under different brands, which means USERS database would be different , but the CARS database would be shared between the application ?
I would strongly suggest that you have a rental microservice to coordinate the process of renting (and returning etc.) a car by a user. Then the logic only appears in the rental service, not spread out over however many other services (counting UIs and such as services for this purpose).
I would actually question whether different brands would need fully-different user services, because there'd be a lot of common functionality. It might make sense to have a general user service with brand namespaces user IDs (so that, for instance, the rental service doesn't need to know about brands) and some brand-specific facades (e.g. to add the namespace to the IDs and maybe even handle things like frequent renter programs).
Related
Let’s assume I’m in the context of an admin panel for a webshop. I have a list of orders. Those orders are payed for and are ready to ship. The (admin) user would like to start making shipments based on the items ordered.
Imagine there are 2 microservices. One for orders and one for shipments. In order to create a shipment, i will send a request with a couple of items to be shipped and an order ID to the shipment service. The shipment service will then check whether the items are present in the order by querying the order service. Because i don’t want to create a shipment with items that are not present in the order.
I’d like to have immediate consistency because the shipment data will be send to a third-party application after creation. Thereby it also feels weird to allow shipments to be created if the data is not correct.
I’m also using GraphQL mutations. Which means i have to return the updated state to the user, which also makes eventual consistency a lot harder.
What is the recommended approach for these situations? Could this be a sign that these 2 microservices need to be merged? I can imagine this situation can occur multiple times.
I have started learning and building micro service based project, but I always stuck into scoping situation and end up creating a sort of monolith. in my below foo-bar example, please suggest what should be the scoping and how achieve desired output.
Services or tables
Employees
Department
Employee-Department-Mapping
Assumption
Employee or Department does not have any cross reference for each other all relationships are maintained in 3rd table Employee-Department-Mapping
Relationship could be One-To-Many or Many-To-Many based on business to business, in this example it is One-To-Many (Department with Employee)
Requirement
I want to get total salaries paid department wise. similar to below query, here I am making simple joins on 3 tables. which is only possible if all are in the same database and single micro service.
Select d.DepartmentName, SUM(e.salary)
from Employee e, Department d, Employee-Department-Mapping c
where d.DepartmentName == c.DepartmentName
AND e.Employee == c.Employee
Group By c.DepatmentId
constraints
employee table has salary information
employee department relationship is maintained by 3rd table.
I am not looking for exact answer but an approach to solve such problems.
wonder how would you design your micro service if you need aggregated outputs, would you bring all these tables in the single microservice ? I do not want pull millions of records from everymicroservice and do aggregation in memory.
Microservice boundries -if you don't have any other scalability reason- should be defined by the business. And in this particular case -without knowing any other requirements- I would say you should go for one microservice which manage those 2 entities. Having said that I experienced enough to know that in the real world this solution is not always feasible and possible. Fortunately there are some patterns you can follow to fix the situation you described. For example CQRS could be a solution https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing.
You have to change your thinking to microservices here. what I can propose here is
You will have to do multiple calls to different microservices and return one result you can use API Gateway pattern. You will have to write an aggregator service to aggregate the output of the two tables via two API services.
You will have to denormalize the database and have the dept name in your Employees table if you don't like the above option. That's why we use NoSQL in microservices.
When employees log in through
site.com/employees/login
They get to access the vendor_companies table through
App\Models\Employee\VendorCompany Model
When vendors log in through
site.com/vendors/login
They get to access the vendor_companies table through
App\Models\Vendor\VendorCompany
Is this approach ok?
Although having a single model is most common, what you have is fine. There are times when you want to do customization in one model depending on how you want to treat Vendors. Two different models allow you to have a cleaner separation and makes it easier to maintain functionality, especially between two teams - one team that builds vendor features vs. other team that builds features for employees.
When you build your controllers, you will have to put additional effort to identify whether you are dealing with vendor or employee and then call the appropriate model.
On the flip side, it is common to have a single model and you have customization based on vendor or employee. Give your method a shot and try your methodology.
I want to use the many to one and other DB Relationship in micro-service architecture. In monolithic architecture we can create the entity relationship easily as they belongs to same project but in micro-service architecture how we can achieve the same.
Example:
There is one userDeatil service and other is productDetail service.Now there is third service called orderDetail and an order will have userID and ProductIDs associated with it. So how can we manage the relationship between 'user and order' and 'order and product'.
I have searched over net but didn't able to get the fair idea.There is another thread having same query but not having the clear answer. Link
In my opinion your case is about how you specify your services especially how you define the bounded context of each service !!
According to the situation above-mentioned I don't see any reason why the product service should know anythings about orders (even if it s just the order-id) and backwards. One more problem I see in this case: your services will not work if one service is not available (E.g when the product service it not online, your order service will not be able to work, because he needs the product details from the product service...).
I Think you should rethink the bounded contexts of your microservices. You should keep in mind:
ensure a loose coupling of the microservices
a microservice has always to work even other Microservices are not available (Resilience / Reliability).
The DDD (domain-driven-design) paradigm with its tools provides her a great help to assist you, during the definition process of your services, you encourage these qualities.
So, the following is JUST an idea (it s not a recommendation and you should review whether it matters for your business case) :
It seems like the "order" process is your core business domain. So you have to focus on it.
The user service (i hope you mean here the customer and not a user in terms of authentication/authorization) has only the responsibility to manage the customers, and may be their adresses, bank-Accountings etc.. It should not know anything about your orders or products.
The same is valid for the product service. It owns only data about products. It has no relation either to the customer nor to the order-service.
The order service by itself deals only with orders and should own only data that belong to an order (like ship Adress and some information about the product-items ordered). I think the customer-Id is also important here to keep the relation between the order and the customer. This way you can e.g get all orders made by a certain customer-id....
A user requests latest news , the news get data from multiple sources (posts, users , photos, comments) . How would you model the news?
Is it good to have a gateway that couples these tables + a service that gets the data from the coupled gateway and handles the data as a response ? Or a domain model that couples the other models (this would mean to add in one of those gateways a joined long query that , in my opinion needs a separate gateway ).
I would create a NewsService, as it would be coordinating the creation of the news, but would defer any specific responsibility to the appropriate model. If it's a news feed, like in facebook, I would create another model, NewsItem which is created upon the entry of a new post, photo etc. This way, the responsibility of build the news would fall more into your domain model and your NewsService would be really just orchestrating the construction of the list. You could even, depending on your app, just use a NewsRepository.