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

ramneekh
ramneekh Member Posts: 4
edited October 2020 in General Discussions #1

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

  • arih
    arih Member, Employee Posts: 125 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: https://youtu.be/1hwuWmMNT4c

    --
    Ari

  • Aaron
    Aaron Member, Administrator, Moderator, Employee Posts: 508 admin
    edited October 2020 #3

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

  • Tamimi
    Tamimi Member, Administrator, Employee Posts: 491 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

  • nram
    nram Member, Employee Posts: 80 Solace Employee
    edited October 2020 #6

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

  • arih
    arih Member, Employee Posts: 125 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/