CODEWITHSUNDEEP
restapache-kafkamicroservicesmessage-queuemessaging
user1955934
user1955934

Reputation: 3495

Microservices: API Call Vs Messaging. When to Use?

I know that messaging system is non blocking and scalable and should be used in microservices environment.

The use case that i am questioning is:

Imagine that there's an admin dashboard client responsible for sending API request to create an Item object. There is a microservice that provides API endpoint which uses a MySQL database where the Item should be stored. There is another microservice which uses elastic search for text searching purposes.

Should this admin dashboard client :

A. Send 2 API Calls; 1 Call to MySQL service and another elasticsearch service

or

B. Send message to topic to be consumed by both MySQL service and elasticsearch service?

What are the pros and cons when considering A or B?

I'm thinking that it's a little overkill when only 2 microservices are consuming this topic. Also, the frequency of which the admin is creating Item object is very small.

Upvotes: 4

Views: 6039

Answers (2)

Johnny
Johnny

Reputation: 15413

Like many things in software architecture, it depends. Your requirements, SLAs and business needs should make it clearer.

As you noted, messaging system is not blocking and much more scalable, but, API communication got it pluses as well.

In general, REST APIs are best suited to request/response interactions where the client application sends a request to the API backend over HTTP.

Message streaming is best suited for notifications when new data or events occur that you may want to take action upon.

In you specific case, I would go with a messaging system with is much more scalable and non-blocking.

Upvotes: 4

Squake
Squake

Reputation: 427

Your A approach is coupling the "routing" logic into your application. Pretend you need to perform an API call to audit your requests, then you will need to change the code and add another call to your application logic. As you said, the approach is synchronous and unless you're not providing threading logic, your calls will be lined up and won't scale, ie, call mysql --> wait response, then call elastic search --> wait response, ... In any case you can prefer this approach if you need immediate consistency, ie, the result call of one action feeding the second action.

The B approach is decoupling that routing logic, so, any other service interested in the event can subscribe to the topic and perform the action expected. Totally asynchronous and scalable. Here you will have eventual consistency and you have to recover any possible failure.

Upvotes: -1

Related Questions