micro service design business and user RestAPI

Question

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.

Answer 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