How to implement event payload isolation in an event driven architecture?

Question

I have an event, let's say order.placed The payload consists of some general information about the order and 3 confidential fields. For example part of the message should only be visible to consumer A, part to consumer B and part to consumer C.

Does any pattern exist to handle this kind of requirement?

I considered encrypting these parts of the message with different keys, so only consumers for which this data should be available be able to decrypt this part of message.

I also thought about sending the same message with three different payloads for each consumer.

Have you tried any of these approches, maybe there are others?

• Ewan: If consumers can only read part of the message, you essentially have three message types. Can you tell use what the encrypted fields are and why the consumers aren't allowed to see them?
• Kamil Latosinski: Some sensitive information, let's say payment details, which are not required by loyalty service to do it's job. All of the services care about order.placed but each of them need slightly different set of data, of which some is sensitive and it doesn't seem right for me that I give every service the possibility to read that data.
• Ewan: I mean it sounds like payment data would be on payment.made rather than order.placed? is the problem that you have only a few, large, events with lots of data?
• Ewan: im just thinking obviously sensitive stuff like payment details, you would expect to be excluded from most events, what kind of event do you have that has 3 different kinds of secret data
• JimmyJames: If you go with the encryption approach, you need to implement some sort of key management you should have a plan for what you will do if/when a key is compromised. Also realize that if you are using PKI for this, the overhead of encryption and decryption is a lot higher than what you see with typical HTTPS interactions.

Answer 1

Another approach/option is to send one message with the minimum amount of information so every consumer can use the message. Once the message is read, they could call an API => getOrderDetails() which will return additional information. Assuming they authenticate, the API can authorize which part(s) order details can be sent to the caller of the API.

This way the message doesn't have any logic inside of it of what parts can be read by individual consumers.

• Rik D: One of the benefits of an event driven architecture is to not have this kind of dependency.
• Kamil Latosinski: Yes, I did consider that, however the big downside of that approach is increased load on the producer. But it's one of the options.
• Jon Raynor: Thanks for the comment. Probably different messages/queue for each consumer type. You could control access that way and ensure no data (encrypted or otherwise) would be in message/queue for a particular consumer type. So, each message has exactly what is needed and nothing more.
• JimmyJames: @RikD That's true, to a point. In practice, I find that this kind of approach is necessary to make such systems robust. It can also be a much simpler solution for many problems that can be difficult or even intractable with a pure event-driven design.
• JimmyJames: "the big downside is increased load on the producer" I think I understand your point but it's not really that cut-and-dried. A lot of that depends on the architecture of your solution. For example, the size of messages in such an approach can be much smaller, reducing the load and storage requirements for your messaging platform.

Answer 2

It seems unusual to have data in an internal communication between software services that should be visible to some consumers and hidden from others. So I would guess that there isn't a common pattern for this situation.

That said, if you really need it, either of your approaches would work (as it would when communicating with external untrusted entities).

• Kamil Latosinski: Good point. For example loyalty service doesn't need data that is designated for payment service. It bothered me that it might be kind of a security issue that my loyalty service can read payment data from the message, but maybe it's not that big of an issue and I should trust my own services.
• Ewan: I think you might be breaking some laws, or at least annoying your bank, if you start sending unencrypted cc details around needlessly
• Kamil Latosinski: The payment details is just an example out of the blue. I'm not sending cc details around. For the discussion we can just assume it's secret data, whatever that is.