Chapter 3. An in-depth tour of message properties

 

This chapter covers

  • Message properties and their impact on message delivery
  • Using message properties to create a contract with publishers and consumers

In chapter 1, I detailed how I set out to decouple member login events from database writes that were causing delays for members logging into a website. The advantages of doing so quickly became clear to our entire engineering organization, and using a loosely coupled architecture for database writes took on a life of its own. Over time, we began to leverage this architecture in new applications we were developing. No longer were we just processing member login events, we were using this architecture for account deletions, email message generation, and any application event that could be performed asynchronously. Events were being published through the message bus to consumer applications, each performing its own unique task. At first we put little thought into what the message contained and how it was formatted, but it soon became apparent that standardization was needed.

3.1. Using properties properly

3.2. Creating an explicit message contract with content-type

3.3. Reducing message size with gzip and content-encoding

3.4. Referencing messages with message-id and correlation-id

3.5. Born-on dating: the timestamp property

3.6. Automatically expiring messages

3.7. Balancing speed with safety using delivery-mode

3.8. Validating message origin with app-id and user-id

3.9. Getting specific with the message type property

3.10. Using reply-to for dynamic workflows

3.11. Custom properties using the headers property

3.12. The priority property

3.13. A property you can’t use: cluster-id/reserved

3.14. Summary

sitemap