CODEWITHSUNDEEP
microservices
Swordfish
Swordfish

Reputation: 1281

Notification microservice API or queue

I'm new to microservices architecture and want to create a centralised notification microservice to send emails/sms to users.

My first option was to create a notification Kafka queue where all other microservices can send notifications to. The notification microservice would then listen to this queue and send messages accordingly. If the notification service was restarted or taken down, we would not lose any messages as the messages will be stored on the queue.

My second option was to add a notification message API on the notifications microservice. This would make it easier for all other microservices as they just have to call an API as opposed to integrate with the queue. The API would then internally send the message to the notification Kafka queue and send the message. The only issue here is if the API is not available or there is an error, we will lose messages.

Any recommendations on the best way to handle this?

Upvotes: 5

Views: 4134

Answers (1)

James Russell
James Russell

Reputation: 66

Either works. Some concepts that might help you decide:

A service that fronts "Kafka" would be helpful to:

  1. Hide the implementation. This gives you the flexibility to change Kafka out later for something else. Your wrapper API would only respond with a 200 once it has put the notification request on the queue. I also see giving services direct access to "your" queue similar to allowing services to directly interact with a database they don't own. If you allow direct-access to Kafka and Kafka proves to be inadequate, a change to Kafka will require all of your clients to change their code.
  2. Enforce the notification request contract (ensure the body of the request is well-formed). If you want to make sure that all of the items put on the queue are well-formed according to contract, an API can help enforce that. That will help prevent issues later when the "notifier" service picks notifications off the queue to send.

Adding a wrapper API would be less desirable if:

  1. You don't want to/can't spend the time. Maybe deadlines are driving you to hurry and the days it would take to stand up a wrapper is just too much.
  2. You are a small team and you don't have the resources/tools/time for service-explosion.

Your first design is simple and will work. If you're looking for the advantages I outlined, then consider your second design. And, to make sure I understand it, I would see it unfold like:

  1. Client 1 needs to put out a notification and calls Service A POST /notifications
  2. Service A that accepts POST /notifications
  3. Service A checks the request, puts it on Kafka, responds to client with 200
  4. Service B picks up notification request from Kafka queue.

Service A should be run as multiple instances for reliability.

Upvotes: 5

Related Questions