Design Patterns express a problem in a context with a reusable solution.
By
Mathias Verraes
Published on 02 July 2019
I wrote about something that I called the Forgettable Payload pattern. The abstract reads “Store the sensitive payload of an event in a separate store to control access and removal.” Please read the full pattern first. In short, it’s about being able to remove sensitive information from an eventstore, for example upon receiving a deletion request under the GDPR.
Some readers have remarked that Forgettable Payloads is the same the Claim Check pattern. Enterprise Integration Patterns describes the problem that Claim Check solves as:
“How can we reduce the data volume of a message sent across the system without sacrificing information content?”
The solution of both patterns is pretty much identical:
UserUploadedImage { userId:12, image: "...huge binary blob goes here" }
// Refactored using Claim Check pattern:
UserUploadedImage { userId:12, imageUrl: "http://...photo12.png" }
UserHasRegistered { userId:12, name: "Mathias Verraes", address: "..." }
// Refactored using Forgettable Payloads
UserHasRegistered { userId:12, payload: "b167a587-1f1f-45bf-bd41-af3e7a1aabd1" }
In both cases, the actual payload of the message is replaced by a reference to a separate store that holds the payload.
Does this mean that Claim Check and Forgettable Payloads are the exact same pattern? I’d argue they’re not. A pattern consists of a problem and a reusable solution. If the problem is different, the pattern is a different one.
Forgettable Payloads is specifically about being able to delete information in an eventsourced system, without touching the eventstore. The same problem can be solved in different ways, for example using Crypto-Shredding.
Claim Check is specifically about reducing message sizes (and is not limited to eventsourced systems). We can also reduce messages sizes by splitting them into smaller ones, called Message Sequence in Enterprise Integration Patterns.
(Enterprise Integration Patterns does mention that Claim Check could be used to hide information. It makes no mention of deleting the information. The book was written many years before GDPR, so the authors can be forgiven for not recognising Forgettable Payloads as a separate pattern. In all fairness, using Claim Check for sensitive information is only mentioned as an option in passing, and does not seem to be part of the actual pattern.)
We must remember to think of a design pattern as “a problem in a context with a reusable solution”, not merely “a reusable solution”. If two patterns have identical solutions, we should not think of them as the same pattern. A solution that is great for one problem, could be a terrible idea for another problem. As our understanding of the problems evolve, their solutions could diverge in entirely separate directions. The problems themselves could evolve separately as well: the technical restrictions to large message sizes may disappear, while the need for robust privacy solutions may increase.