In modern distributed systems, messaging plays a pivotal role in enabling reliable communication between services. Azure offers a robust ecosystem of messaging services, from Service Bus for enterprise messaging to Event Hubs for real-time event streaming, and Storage Queues for simple queue-based communications. These services form the backbone of many cloud-native applications, allowing systems to scale independently, maintain loose coupling, and ensure reliable message delivery.

However, as applications grow in complexity, they often need to handle larger messages containing images, documents, sensitive information or complex data structures. This is where traditional messaging patterns face challenges – message size limits, increased latency, and higher costs can impact system performance. Enter the Claim-Check pattern, an elegant solution that addresses these limitations while maintaining the benefits of message-based architectures.   

Your Messages’ Valet Service 

Here we introduce the claim-check pattern, which is an elegant design pattern helping address the limitations listed above, helping you build a resiliency around your message-based architecture. 

By using the claim-check pattern, large messages no longer must be sent to messaging systems. Instead, the content/payload of the message can be sent to an external data store such as Azure Storage Accounts. A claim-check token is created which has references to the payload in the data store. This token is then sent to the receiving application (the subscriber) which can be used to retrieve the payload from the data store. The below diagram depicts the payload flow: 

Supporting the Well-Architected Framework Pillars 

This design pattern helps workload’s address different pillar goals in the Azure Well- Architected Framework, making it even more valuable when designing complex solutions. There are four pillars which this pattern supports: 

Reliability 

Messaging systems generally do not provide reliability and disaster recovery features present in dedicated data stores. Whilst messaging systems do offer dead lettering of failed messages, there is no way to retrieve successfully processed messages. 

With the use of data stores, messages can be archived and referenced at a later stage if required. Also the separation will help increase redundancy, allowing for payloads to be easily recovered in the event of a disaster. 

Security 

One other benefit of the claim-check pattern is the assurance of confidentiality and integrity of payloads being processed. Through the storage of payloads in an dedicated data store, sensitive data is extracted from the message. 

This will allow the configuration of more strict access controls, ensuring only services required have access to retrieve sensitive information. It will also help mask data from unrelated services. 

Cost Optimisation 

Messaging systems such as Service Bus on Azure usually have message size limits. Increasing these limits often rely on increasing service plans to Premium, leading to higher costs. 

For instance, the maximum message size of a Standard tier service bus is 256KB. A Premium tier service bus allows messages up to 100MB in size.  

A Standard Service Bus is approximately AUD$15.76 a month, whilst a Premium instance will cost approximately AUD$1087.23 per month. By reducing the message size, the cost of using messages services can be dramatically reduced. 

Performance efficiency 

Efficiency is also improved when message size is reduced. When a message is stored in data stores, it can be ensured that receiving applications only access large message when needed. 

Extra considerations

No pattern is perfect. There will always be extra considerations and requirements when implementing a solution or pattern. Since we are introducing a data store for storing our payloads, consumed data will not be automatically deleted. Above we mentioned that this is a strength of our Claim-Check pattern and aligns with the reliability pillar and it does. But it is crucial to decide whether archiving of messages is always required. 

Deleting of consumed messages should be considered by following the below suggested patterns.

In-process deletion  

The subscriber application will delete the message immediately after consumption 

External service 

Another application outside of messaging solution will delete payloads. This helps decouple the messaging solution with required data governance policies. 

Conclusion 

The Claim-Check pattern stands as a testament to elegant solution design in modern cloud architectures. By strategically separating large payloads from message delivery, it not only solves immediate technical challenges like message size limitations but also strengthens multiple pillars of the Azure Well-Architected Framework. 

From enhancing security through better access controls to optimising costs by enabling the use of lower-tier messaging services, the pattern delivers tangible benefits across the board.  

While considerations around data lifecycle management require careful planning, particularly regarding cleanup strategies, the pattern’s ability to improve reliability, security, cost efficiency, and performance makes it an invaluable tool in any architect’s arsenal.  

Whether you’re dealing with large documents, complex data structures, or sensitive information, the Claim-Check pattern offers a robust and scalable approach to message processing in Azure applications.