Book Image

Architecting Data-Intensive Applications

By : Anuj Kumar
Book Image

Architecting Data-Intensive Applications

By: Anuj Kumar

Overview of this book

<p>Are you an architect or a developer who looks at your own applications gingerly while browsing through Facebook and applauding it silently for its data-intensive, yet ?uent and efficient, behaviour? This book is your gateway to build smart data-intensive systems by incorporating the core data-intensive architectural principles, patterns, and techniques directly into your application architecture.</p> <p>This book starts by taking you through the primary design challenges involved with architecting data-intensive applications. You will learn how to implement data curation and data dissemination, depending on the volume of your data. You will then implement your application architecture one step at a time. You will get to grips with implementing the correct message delivery protocols and creating a data layer that doesn’t fail when running high traffic. This book will show you how you can divide your application into layers, each of which adheres to the single responsibility principle. By the end of this book, you will learn to streamline your thoughts and make the right choice in terms of technologies and architectural principles based on the problem at hand.</p>
Table of Contents (18 chapters)
Title Page
Packt Upsell
Contributors
Preface
Index

Dead-Letter Exchanges


Dead-Letter Exchanges (https://www.rabbitmq.com/dlx.html) are used when the consumer cannot handle a particular message. It is typically used for answering questions such as:

I have a message in my queue that I do not know how to process successfully. I have tried processing it many times and I am sure I cannot handle it. What should I do?

I also have messages in my queue that are bad, as I don't know their syntax at all or they do not meet the business requirements. What should I do?

In Data Bus Implementation, we will define a Dead-Letter Exchange of the Direct Exchange type, to which all the messages that cannot be processed will be sent. We will do an explicit "reject" of the message and will NOT put it back in the queue.

The component rejecting the message will need to provide the following details:

  • Correlation ID
  • Message Payload
  • Message Metadata

A dead-letter Exchange will have multiple queues bound to it based on the routing key.

A message will be considered dead when...