Design a microservice to communicate by messaging and RESTful API

user_12756301 0
Viewed 80

I'm in the process of designing a microservice for a specific business domain.
The requirements for the service are:

  1. Expose a synchronous communication channel using RESTful API.
  2. Communicate asynchronously via messaging off a broker. (will account for most of the traffic).

Note: The business logic layer is the same for both communication styles.

So far I have 2 approaches in mind:

Approach 1

  1. Extract the business logic layer of the service to a centralized core repo.
  2. Reuse the business logic layer in 2 different codebases, one for REST one for messaging.
  3. As a result, the 2 different codebases run as 2 different processes and are also provisioned separately.

Approach 2

  1. Given that the service code is architected in a manner that allows the client and business logic layers to be switched interchangeably.
  2. Implement 2 different app entry points that utilize the same BL layer: A. Run as a server that subscribes on topic B. Rub as a server that exposes RESTful API.
  3. Deploy the same codebase with different configs to establish different communication styles.

My approaches might be Ill formed to begin with, I'd be happy to hear how you'd fulfill the requirement. What would be the best practice for this situation?

Thanks in advance

microservices messaging rest
1 Answers

I would in general tend to deploy the same codebase such that each deployed instance can both subscribe to a topic and expose a RESTful API. For example, the entrypoint of the main process could both start an HTTP server and initiate topic subscription.

If a framework/library made doing this impractical, I would firmly consider that a negative. At the very least there's often a good reason for a service which primarily receives messages via topic subscription to be able to receive control messages via HTTP (e.g. "stop consuming").

user_56412440
Related