Architecture Patterns - Claimcheck & Bulkhead

 

Claim-Check pattern

Device message into Header-Body > Store body in DB > Send header as event > Subscriber/event receiver will access header > Header points to body/Actual message stored in DB.

A messaging-based architecture at some point must be able to send, receive, and manipulate large messages. Such messages may contain anything, including images (for example, x-ray scans), sound files (for example, call-center calls, video file contents), text documents (for example, Invoices), or any kind of binary data of arbitrary size.

Sending such large messages to the message bus directly is not recommended, because they require more resources and bandwidth to be consumed. Large messages can also slow down the entire solution, because messaging platforms are usually fine-tuned to handle huge quantities of small messages. Also, most messaging platforms have limits on message size, so you may need to work around these limits for large messages.

1. Send message
2. Store message on the data store
3. Enqueue the message's reference
4. Read the message's reference
5. Retrieve the message

Bulkhead pattern

Isolate resources to consume backend services

If a client needs to process 10,000 messages, but clients 2 and 3 only have 200 to process, you cannot afford to let client 1's overload delay clients 2 and 3. Instead, you can divide the microservices using autoload balancers or auto scale to ensure that all clients are served on time.

Note: Bulkhead is not a cost-effective solution but definitely the one if you are looking for the resilient solution. You can always use circuit breakers to check each service instance's performance and load to save the resources and cost.