Scenario I receive a message in a specific "address" in Vertx eventbus - the message can be of four types. The handler should process the message and send the result to another eventbus "address", its handler posts it to an external-service api. Problem How to design the Verticle for this? I have described two approaches below - which one is efficient, faster and is able to scale well, considering this will be deployed in Kubernetes. How about worker verticles? Any other effective approach I am missing? The approaches Write a verticle for each type, with an eventbus consumer consuming and processing this type. Send the processed data to the "external-service-call" address. Write only one verticle - the eventbus handler can decide and invoke appropriate method based on the type of message, finally publish it to an the "external-service-call" address. To my understanding, I can scale the second approach by deploying multiple instances of that verticle. By scaling I mean this can accept and process much volume concurrently? How about the first approach? Other approach you think I should know?

Reputation: 2912

Vertx - multiple vs single verticle for event processing

Scenario

I receive a message in a specific "address" in Vertx eventbus - the message can be of four types. The handler should process the message and send the result to another eventbus "address", its handler posts it to an external-service api.

Problem

How to design the Verticle for this? I have described two approaches below - which one is efficient, faster and is able to scale well, considering this will be deployed in Kubernetes. How about worker verticles? Any other effective approach I am missing?

The approaches

Write a verticle for each type, with an eventbus consumer consuming and processing this type. Send the processed data to the "external-service-call" address.
Write only one verticle - the eventbus handler can decide and invoke appropriate method based on the type of message, finally publish it to an the "external-service-call" address.

To my understanding, I can scale the second approach by deploying multiple instances of that verticle. By scaling I mean this can accept and process much volume concurrently? How about the first approach?

Other approach you think I should know?

Upvotes: 1

Answers (2)

Bhargava Kulkarni

Reputation: 1

Approach 1: a. More cleaner. eventbus is designed to for communicating between the verticles of same vertx instance or within cluster verticles. b. Performance - Since verticles are on the same host, so no network IO and not much performance impact.

Approach 2: a. Less cleaner but will gain very small amount of perf improvement which is negligible compared to the external service calls b. Not good from maintainability point of view.

I would probably choose approach 1.

Upvotes: 0

Alexey Soshin

Reputation: 17701

First approach is slightly more preferable for two reasons:

Doing less checks => Less CPU time => more concurrency
Less code in each verticle => easier to maintain

Having said that, that's not something that should concern you. Your external-service-call will be by order of magnitude slower than any micro-optimisation on EventBus.