Which is more appropriate in a Rest environment, WebClient (webflux) and saga pattern vs Kafka?
If we assume we have this scenario and the microservices are:
A -> B -> C (Introduced)A -> B -> D (Introduced)A -> B -> E -> F -> G (Error)
(Microservice B introduces microservice C and D)
Webclient is async. Also, if a point from A to Z failed, "exactly" the same thing would happen to Kafka. Why would the same thing happen to it?
- Webclient without saga pattern:
C and D are incorrect or inconsistent.
- Kafka:
The same thing happens in Kafka. When they listen to channel C and D they will simply enter it. When it reaches F, then Kafka will have already entered that data into the other microservices. Kafka will have already sent the request to send within the listener.
As much as it is "persistent" the data will have already been entered into C and D and even if you have saved (persistence) the messages from "F", and "F" in the future will read that data again and if "F" is full (no more products can be registered), C and D are inconsistent.
Therefore,
- Webclient: It is a round trip request, because we can get the returned data from that endpoint. Usually json.Much simpler than setting up another listener to consume as in Kafka.
- Kafka: It is only a one-way request (with persistence), but it has no return (unlike WebClient which checks the HTTP back), that is, if it is not listened to again (create a consumer again) the data falls into limbo.
WebClient + Saga pattern solves this. The saga pattern ensures that data is consistent across microservices. It's pretty simple to do.
It is a simple pattern and WebClient solves this problem.
My question is, why do I see a lot of Kafka in Rest services?
1 - Decoupling? Both need to know something.
- Kafka: Needs to know the topic/channel to listen on
- WebClient: Needs to know the endpoint that makes the request
2 - Persistence and reproducibility:
- As we have said in the example of the "F" case, it will also be inconsistent no matter how much persistence there is.
3 - High availability: Both are high availability, that is, http requests are made in thousandths of a second.
4 - Handling high loads:
- Kafka: OK
- Webclient (webflux): it is asynchronous so it is not blocking. The same as Kafka, so . In addition, as stated, the Http protocol can handle many requests in less than a second..
5 - Support for messaging patterns:
- Kafka: OK
- WebClient: Does not support this.
6 - Integration with big data ecosystems:
- Kafka: OK
- WebClient: Does not support this.
7 - Data fetching
- Kafka: Not supported. Unless you listen to the response (create another producer and consumer for the response)
- WebClient: OK. In the same request to the endpoint you retrieve the data from that endpoint.
Also, WebClient is from the SpringBoot ecosystem, that is, from the native house itself. If there are ever any improvements, it comes directly from the creators of Spring.
An answer on why to use Kafka over WebClient (webflux) and saga pattern in a REST environment.
Note: Evidently each one can be complementary and none replaces the other and each one solves a specific scenario.It's just that I see opting for Kafka as a trend or fashion.That's obvious. But I follow the KISS principle.