0

I want an advise according usage of spring cloud stream technologies. Currently my service use spring-boot and implements some event-based approaches. But the events are not sent to some kind of broker, but are simply handled by handlers in separate threads. I am interested in spring cloud stream technology. I have implemented CustomMessageRoutingCallback as shown in this example https://github.com/spring-cloud/spring-cloud-stream-samples/tree/main/routing-samples/message-routing-callback. But the problem, that declaring all consumers at config in this way sounds like a pain:

@Bean
    public Consumer<Menu> menuConsumer(){
        return menu -> log.info(menu.toString());
    }

Because I have around 50-60 different event types. Is where any way to register consumers dynamicly? Or the better way will be declare consumer with some raw input type, then deserialize message in consumer and manually route message to the right consumer?

Tomas0808
  • 47
  • 5

2 Answers2

1

This really has nothing to do with s-c-stream and more of an architectural question. If you have 50+ different event types having that many diff3rent consumers would be the least of your issues. The question I would be asking - is it really feasible to trust a single application to process that many different event types? What if a single event processing results in the system failure. Are you willing to live with non of the events being processed until the problem is fixed? This is just an example, but there are many other architectural questions that would need to be answered before you can select a technology

Oleg Zhurakousky
  • 5,820
  • 16
  • 17
  • That’s makes sense, thank you. In my case “events” used for the internal application communication, not for communication between services. And such events were introduced by me to prepare application for horizontal scale. – Tomas0808 Oct 01 '22 at 18:23
0

A possible option is to create a common interface for your events

@Bean
public Consumer<CommonIntefaceType> menuConsumer(){
    return commonIntefaceTypeObj -> commonIntefaceTypeObj.doSomething();
}
Pavlo Kuchereshko
  • 74
  • 8