Reputation: 5500
I'm receiving messages from a pub/sub push subscription.
Here's the payload of one such message in raw bytes:
REQUEST_BODY b'{"message":{"attributes":{"one":"two"},"data":"InN0dWZmIg==","messageId":"5481363137518973","message_id":"5481363137518973","publishTime":"2022-08-24T16:39:11.08Z","publish_time":"2022-08-24T16:39:11.08Z"},"subscription":"projects/my-project/subscriptions/my-subscription-name"}\n'
Notice that in the message there are two duplicated values:
messageId
vs message_id
publishTime
vs publish_time
Now, I'm aware that some languages and styles prefer snake versus camel cases, and I'm not getting into what's right...
But objectively there should be only one for transmission over the wire, rather than sending BOTH!
I don't care which gets used, but I do care that I'm getting charged for this bandwidth!!
Why does GCP do this, and can I turn it off?
Upvotes: 0
Views: 684
Reputation: 12233
I believe this is for backward compatibility. I think message_id was introduced earlier and then they changed it to messageId. In order to not break the existing code that someone may have written using message_id, they left it there and added messageId. Same thing applied to publishTime.
AFAIK you cannot turn it off.
Did some research on pricing. If I understand it correctly, you are not charged for Egress from pub/sub if your subscriber is in the same region as your pub/sub topic.
I am not sure about Throughput cost. Does it charge for the entire message body including the attributes added by Google or just for the data/attributes part (that you published)? I guess, someone from Google can answer that.
Thanks @KamalAboul-Hosn. I also found this excerpt on Pub/Sub pricing page on Google:
The data volume of a message is the sum of the sizes of the following message attributes:
- The number of bytes in the encoded message body string
- For each attribute, the size of the key and its value
- 20 bytes for the timestamp
- The size of the message_id string
- The size of additional optional fields, such as those associated with early access and other restricted-access APIs.
Upvotes: 2