Message validation in async messaging-based services

Question

I'm looking for information on the best approach to message validation in asynchronous-messaging-based services (i.e. services that pull messages from some sort of message queue or broker, rather than providing an HTTP-based API or something similarly request-response oriented).

In an HTTP API, if the message is invalid (wrong fields, invalid JSON/XML/Whatever) you can return a 400 error. The receiving service can go on as before, and the sender has to deal with the error. (Many HTTP libraries raise an exception when a non-200 response is returned, making the source of the problem very clear.)

With async messaging processes, I can think of a few approaches:

1. The receiving process deals with the error somehow.
2. The receiving service just ignores messages that are not valid.
3. The receiving service logs the invalid message and then moves on to the next message. If things don't seem to be working correctly, hopefully, we can locate the problem in the logs.
4. The receiving service sends an error notification back on some sort of a response channel.

None of these options seem particularly good.

Option (1) is really just a "hand-wave" in the direction of some as-yet-unknown solution.

Options (2)-(3) seem to run the risk of problems in the sender's code being masked and made difficult to identify (compared to the request-response situation, where you can immediately identify a 400 response, which occurs in a "location" very closely linked to the source of the error).

Option (4) seems to be attempting to recreate a request/response system, negating any reasons for opting for an async-messaging based system. If you're going to request/response, why would you be using a message-broker based system in the first place?

I would appreciate any information on best practices, and on how the tension described above might be resolved.

Answer 1

Most^* Message Oriented Middleware platforms provide a mechanism for the schematic validation (i.e. against a schema) of incoming messages as they are enqueued. This is logic that checks for things like missing/null fields, values outside of certain ranges, bad formatting, etc. But, as these checks are being done by the message broker, and not the end system - cannot check references such as customer ID exists, order exists, etc.

_{* "Most" of the strongly-typed message brokers, not just systems that queue dumb strings.}

For example, in JMS a 'Validator' method can be assigned: https://docs.spring.io/spring/docs/4.1.1.RELEASE/spring-framework-reference/html/jms.html#jms-annotated-method-signature

I believe WCF has something similar, closest thing I could find was this article.

---

As for your options, I believe 4 is probably the most common. There are reasons (to do with scalability) why this response channel is preferable to a request-response driven system (I can validate your message and send you the Exception whenever, rather than tying up a socket + process/thread on each end while you wait for me to do it live, etc).

Answer 2

You can also send the message to a Dead Letter Queue

In message queueing the dead letter queue is a service implementation to store messages that meet one or more of the following criteria :

Message that is sent to a queue that does not exist.

Queue length limit exceeded.

Message length limit exceeded.

Message is rejected by another queue exchange.

Message reaches a threshold read counter number, because it is not consumed.

Sometimes this is called a "back out queue". Dead letter queue storing of these messages allows developers to look for common patterns and potential software problems.

Answer 3

I have been working with a queue based API for some years now and I've found the solution implemented to be working just fine. What they did in this API is this:

1. Client sends a message to be handled to a REST endpoint
2. Message is validated for correctness. If it is not valid the response is an HTTP error, 200 is returned otherwise, containing an id identifying the message in the queue
   3. If some error happens while handling the message, it is logged in a separate log file
   4. A client can always query the queue through a separate endpoint, finding out the current status of the message it queued (or querying for all errors, for example)

HTH.

Answer 4

As far as I have seen in my current project, #4 is the one used - Send the notification back to the source channel if the validation checks fail.

Answer 5

Schematic and other validations which can be done on the request can be done on the sender's end as sender have all the information to validate the request and the queue will not have data which have these invalidations. This can be also useful in the future if a new service wants to listen to the data in queue and process it.

For the errors which can't be validated/prevented by the sender if the sender can do anything useful with the errors which don't fall into the scope of the receiver service, it could be sent back to the receiver through response queue/ error queue, otherwise, they can be logged or alerted at receiver's end. This will reduce unnecessarily creation of response queue in the latter case. In the former case, it seems fine to send the response, if the sender can do something with it which lies in its scope. In both cases, the validation errors will be identified immediately to close to the source of its generation.