Try PubSub+

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

ramneekhramneekh Member Posts: 4
edited October 22 in General Discussions

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?

Comments

  • ariharih Member, Employee Posts: 43 Solace Employee

    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:

    --
    Ari

  • AaronAaron Member, Moderator, Employee Posts: 133 Solace Employee
    edited October 22

    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?

  • ramneekhramneekh Member Posts: 4

    @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?

  • TamimiTamimi Member, Administrator, Employee Posts: 75 admin

    @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

  • nramnram Member, Employee Posts: 3 Solace Employee
    edited October 22

    @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 :-)

  • ramneekhramneekh Member Posts: 4

    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?

  • ariharih Member, Employee Posts: 43 Solace Employee

    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/

Sign In or Register to comment.