0

We are trying to design use case where privilege user can create business (privilege use is business owner). Each Business can have multiple users. For addressing this requirement we are thinking to create three services UserAPI, BusinessAPI and SubscriptionAPI. UserAPI responsible for user creation, deletion, updating and find likewise business and subscription api will do similar operation.

  • /api/v1/users/
  • /api/v1/business /
  • /api/v1/subscription/

For the scenario where we want to create new user for business we are thinking of SubscriptionAPI to be used

Steps as follow:

  • Is business exist “Business API client” will be used to check.
  • Is user already exist for given mobile number “user API client” will be used to check.
  • If above to condition passed, “user API client” will be called for user creation.
  • Above step will provide user id
  • New record in subscription table Subscription_id, business_id, user_id

Request

  • POST /api/v1/subscription/business/{id}
  • Request Body UserVO

UserVO is repeated in SubscriptionAPI – Is this correct?

Also please share view on described service designing, what improvement can be done.

Surendra
  • 71
  • 2
  • 12

1 Answers1

1

If you are trying to have 3 different microservices then you can use Zuul proxy.

Have the Zuul as the API gateway for your services. It act as a gate keeper for all your services. You can define your custom zuul filters like pre, post etc.

What I would recommend according to your specification to use zuul pre-filter and before routing the request to Subscription service, request other two services to get desired inputs.

Here is a link for reference:
https://spring.io/guides/gs/routing-and-filtering/

Use this config to route the request:

zuul:
 prefix: /api/v1
 stripPrefix: false
proxy:
 stripMapping: false
 mapping: /api/v1
 addProxyHeaders: true
routes:
Business-API:
 path: /business/**
 url: http://localhost:8213
 stripPrefix: false
user-service:
path: /user/**
url: http://localhost:8212
stripPrefix: false

Regarding the request payload, you can have whatever payload you need to have. Just keep in mind that all the services must be independently deployable. That means if you are deleting your business, you need to decide what you have to do with your subscription. Cascading could lead you into problems. It's better to invest more time and think through over the domain. If your service has too much dependency on each other better to cluster them as one domain.

I have explained about how to define your domain here:
DB design for microservice architecture

Pang
  • 9,564
  • 146
  • 81
  • 122
Nitish Bhardwaj
  • 1,113
  • 12
  • 29
  • Routing is not the problem, question is related to API (micro-services) designing. – Surendra Jul 10 '17 at 16:23
  • Thanks Nitish for reply. Question was related to how should I design subscription micro service API. As explained in question above user can own business (owner) and each business can have multiple users likewise each user can associate himself to different products (products which belong to subscribed business). To achieve that subscriber API are used for managing user association with business and association between user and product. How should I define Rest URI for subscription API when we want to associate new user with specific business. Or this approach is entirely wrong. – Surendra Jul 11 '17 at 07:21
  • You can use any URI as long as it's uniquely identifiable. It really doesn't matter. The URI what you mentioned in your question looks fine to me.(**/api/v1/subscription/business/{id}**) You can definitely use user object in your request payload as long as you aren't cascading it with user service. (i.e. Not having a service call to create a user in business service ) – Nitish Bhardwaj Jul 11 '17 at 14:23
  • What are the best practises for such kind of scenario where Subscription API are just holding the relation between user and business also relation between user and product relation. And any thought on /api/v1/business/users/{id} URI for Business API is this correct way to do for business creation under user. – Surendra Jul 11 '17 at 14:34
  • Amit, just one thing matters the most when you are designing MS. You should define a domain. Cluster all the related components together and define a domain. As I have specified in my answer, to me, your use, business, subscription service needs to be in a single MS. URI & payload doesn't matter too much. I think my answer has helped you. Please upvote and accept it if it did. If not, comment and help me to help you better. – Nitish Bhardwaj Jul 12 '17 at 01:50
  • What is the reasoning for making Subscription micro service part of Business micro service? Subscription micro service design for maintaining relation between business and its owner, users associated with business. And which product subscribed by user with there history. – Surendra Jul 12 '17 at 05:05
  • It is not independent. It depends on Business, user and product. Please go through the link attached to the answer. I guess you are still not clear on your domains or boundaries you need to define for a microservice. You don't need an architecture where you have to do cascade delete/edit every time throughout the system of microservices. At this time it's just 3 it may be 50 in future. I guess your problem is addressed here, you need to upvote the answer or comment why it's still not answered. – Nitish Bhardwaj Jul 12 '17 at 05:30
  • I am not allow to up-vote the answer. So should I operate subscription related stuff in business micro-service. Though I have different tables which is used for managing relation between user and business relationship and user and product relationship. – Surendra Jul 12 '17 at 05:56
  • At least you can accept the answer by clicking on the tick mark. :) And again, I would say it doesn't matter on the tables to define a MS. What matters the most is you shouldn't have too much network calls in managing your dependent data across the architecture. – Nitish Bhardwaj Jul 12 '17 at 06:45
  • Subscription is dependent on user, business and product then why it should be coupled with only business? why not on user side? And we do have order ms which get information from subscription table or currently from subscription ms. – Surendra Jul 12 '17 at 06:51
  • Thanks Nitish for explanation, Could you help me to understand why subscription should be part of business not user micro-service. – Surendra Jul 12 '17 at 10:28
  • All I am saying is cluster the services which are heavily dependent on each other. Whether it's user, business or subscription, doesn't matter. I am not really familiar with your domain so it's hard to comment on it. I can only suggest you what's the best practice in general which I have already specified in my answer. If you want to talk about your specific requirement, feel free to chat as it's hard to follow up in comments. – Nitish Bhardwaj Jul 13 '17 at 01:33
  • How do I connect with you so that we could have chat - discussion on it? – Surendra Jul 14 '17 at 11:31
  • You can use chat function you StackOverflow if you have permissions for it. – Nitish Bhardwaj Jul 14 '17 at 11:35