Reactive approach micro-services for API integration (direct using WebClient), without MessageBroker

ramneekh

I am implementing microservices however not planning to have any message broker. services will talk to each other with WebClient/web flux. Is there any risk of going production like this? what are the drawbacks like failover/replay?

arih

I think while reactive component helps getting more throughput with their non-blocking feature, they are still basically a one-to-one blocking pattern. I don't think it's risk, but more on what you'll miss out.

You would still have failover capability with simple HTTP load balancers, but yeah you'd miss out on patterns pub/sub, queueing, and replay. In terms of runtime, being able to shock absorb surge of incoming traffic while throttling your back end API calls is one thing of advantage. In terms of design and architecture patterns, you'd get to do things like tossing an event and have multiple systems react to it, and better yet, you can keep adding new subscriber later without having to change any of the existing flows.

On top of that, I'd recommend this talk from Lightbend CTO: https://youtu.be/1hwuWmMNT4c

--
Ari

Aaron

Without something like a service mesh to help traffic manage your communication, it's like a giant spaghetti of point-to-point connections when using direct communication. Using a message/event broker allows you the flexibility of either synchronous or asynchronous communication, eventual consistency, real-time eventing, and 1-to-many delivery with pub/sub. As your system grows, communication becomes much more complex, so using a broker helps . So if it's a very small system, then maybe it should be ok?

ramneekh

@Aaron said:
Without something like a service mesh to help traffic manage your communication, it's like a giant spaghetti of point-to-point connections when using direct communication. Using a message/event broker allows you the flexibility of either synchronous or asynchronous communication, eventual consistency, real-time eventing, and 1-to-many delivery with pub/sub. As your system grows, communication becomes much more complex, so using a broker helps . So if it's a very small system, then maybe it should be ok?

How about designing the services such that there would be minimal communication between them and in future design/release including the message broker. Would that work?

Tamimi

@ramneekh One thing to keep in mind is that you can still design and develop a very simple architecture using an event broker, you dont need to have a complex or complicated architecture to use a message broker. That way you would be building a resilient architecture that can scale down the road

nram

@ramneekh , Loosely coupled architecture & message driven communication is foundational for reactive systems, so starting with that intent will lead to robust and resilient systems from the get-go. As Jonas Boner puts in Reactive Microsystems, we should avoid building Reactive monoliths :-)

ramneekh

Thanks all for the awesome insight. I am in for MessageBroker however, the challenge is how to implement my (reactive) microservices communicating with MessageBroker. Is there any reference to documentation/example/tutorial?

arih

Great! I would say this blog by Marc is a good place to start hands-on! https://solace.com/blog/getting-started-spring-cloud-stream-and-spring-initializr/