Fabulous Claim Check Design Pattern explained in just one minute
--
Asynchronous communication via messaging is common in microservice architectures. Look at Kafka, Amazon SNS or Google PubSub. Those systems handle gigantic quantities of small messages.
What can you do with large messages, like images or audio data? Take Google PubSub as an example. You can only send 200MB per second in most regions. This translates to 100 images.
Imagine Instagram could only handle 100 images per second!
The Claim-Check pattern comes to the rescue. The publisher saves the payload (e.g. images) to a storage system (e.g. a database, S3, …). Then, it sends a message with a reference to the payload, like an URL. The subscriber uses the message to get the payload from the storage.
This way, the messaging system will not become clogged with large messages. It reduces costs. Storage is cheaper than messaging resources. You can add a security layer with this pattern if your storage system enforces access rules.
Higher latency is the price you pay for this. The subscriber calls the storage system. This might happen over the network. Only use this pattern for large payloads to mitigate the downsides.
Find out more about this pattern on Microsoft’s pattern overview or from this blog post.
Where to go from here
- “Release It!*” contains a lot of patterns and tricks on how to design your software. Get it from Amazon: https://amzn.to/3mV76rb *
- Read the classic about design patterns from the Gang of Four. Get it from Amazon: https://amzn.to/3EYK3BU *
Disclosure: Links marked with * are Amazon affiliate links. This means that, at zero cost to you, I will earn an affiliate commission if you click through the link and finalize a purchase.
Want to learn more about Cloud Design Patterns? Check out my other articles!
