CODEWITHSUNDEEP
google-cloud-pubsub
Jason Park
Jason Park

Reputation: 127

is it better to define one topic with different types or to define typed-topic for each type?

is it better to define one topic with different types or to define typed-topic for each type?

For example, 

[topic]
foo

[message]
{
   type: 'x',
   data: [1,2,3]
}

OR

[topic]
foo-x

[message]
{
   data: [1,2,3]
}

According to pub/sub-pricing, it seems that latter case is a little bit cheaper because of the message size given that gross message sent and delivered is the same.

But this is only pricing, I think there may be some empirical design or schema to define message. What could be considered in this case of message?

Upvotes: 0

Views: 356

Answers (2)

guillaume blaquiere
guillaume blaquiere

Reputation: 75940

Prefer the second solution. Indeed, if you want to plug processing (Function, Cloud Run, AppEngine or other compute platform) on a particular topic, you can do it because the topic is typed.

If the topic is not typed, you have to implement a filter in your process to do: "If my type is X then do else exit". And you are charged for this. For example, for function and Cloud Run, you are charged per request and by processing time, the minimal facturation in 100ms -> too much for a simple IF

However, if you want to plug the same function on several topics, you have to duplicate your function (except if you use HTTP trigger)

Hope this help!

Upvotes: 1

Kamal Aboul-Hosn
Kamal Aboul-Hosn

Reputation: 17251

There isn't one right or wrong answer here. In part, it depends on the nature of your subscribers. Are they going to be interested in messages of all types or in messages of only one type? If the former, then a single topic with the type in the message might be better. If the latter, then separate subscriptions might be better. Additionally, how many types do you have? For dozens or more types, managing individual topics may be a lot of overhead.

Price would likely not be a factor. If your messages are large, then the price will be dominated by the contents of the messages. If your messages are small, then they will be subject to the 1KB minimum billing volume per request. The only way the type would be a factor is if you have very small messages, but batch them such that they are at least 1KB.

If you do decide to encode the type in the message, consider putting it in the message attributes instead of the message data. That way, you can look at the type without having to decode the entire message, which can be helpful if you want to immediately ack messages of certain types instead of processing them.

Upvotes: 1

Related Questions