In last project of our company: Client make a request like identity validation, then first layer of our app get client request and produce message on Kafka, our core service consume the message and then make rest request to banking services, and after getting response we produce a response message on Kafka and then first layer of our app deliver message to client. is it true Kafka use case or it is better to removing first layer and Kafka, and use rest services between client and core. thanks
2 Answers
Using an asynchronous messaging system allows you to decouple your services from an availability point of view. This means that if A needs to call B to split some workflow, then with messaging A can do its work without B needing to be up, then B can pick up and continue once it recovers \ comes back up \ etc.
Due to the above, I highly disagree with the accepted answer: you absolutely can use messaging for critical paths of your application! There are reasons to not chose messaging (most nicely covered by the post the other answer links to), but "use messaging for non-critical workloads" is a very bad advice \ heuristic.
Traditionally authentication workloads wouldn't go through the bus tbh, but this isn't because they are important, but rather because you cannot proceed without first going through authentication and because relying on an asynchronous path for authentication on every single call to your service is a very large overhead which provides no benefit if the user is hitting your service to just read some data.
Using kafka for validation at first step is not a good idea. Ideally message queues should be used for non-critical parts of the application.
This question will help you understand the functional differences between REST calls and message queues. You can take your decision based on your use case.
Related