Async design question - Request IDs

  • Thread starter Thread starter Kevin C
  • Start date Start date
K

Kevin C

When designing an asynchronous service-based system, generally speaking
whose responsibility is it to determine when a duplicate request is sent -
the system hosting the service or the feeding systems. Are there any best
practices when it comes to determining duplicate requests in an asynchronous
system.

For example, lets say you have an OLTP system that tracks inventory with
several other applications feeding into the OLTP system. The feeding
applications send messages defined by the OLTP via MSMQ. NOTE: I know that
Txn MSMQ will guarantee delivery once, I am not addressing dups in this
sense. I am speaking more generally about determining dups whether or not
MSMQ is used. Technically speaking, this service could be a web service in
which I wouldn't get the delivered once guarantee.

Here is the dilemma:
#1
Should the feeding system - lets an application that allows for inventory
adjustments - be responsible for tracking its own "pending" adjustments
(ones that have not actually been processed by the OLTP). In other words,
the OLTP allows for a generic "FeedingSystemID-External ID" that it will
check on each request. If the incoming request has the same ID as a
previous one it will be considered a DUP by the OLTP. In this scenario the
"dishing" out of request ID is delegated to the feeding systems, leaving the
OLTP "dumb" in this manner.

#2
The other scenario is that the OLTP has a certain set of unique conditions
it checks before considering a request to be a DUP. In other words, the
OLTP checks the RequestDate, SKU and some other criteria for each request to
determine if the request is a DUP. This scenario puts full responsibility
on the service (in this case OLTP).

#2 seems like the better approach but I was curious if there are any best
practices when it comes to determining duplicate requests when designing an
async system.

Thanks,
Kevin
 
#2 sounds best to me Kevin....

The reciever of the message(pay load) can check the for
authenticity\duplicate\invalid data etc, you wouldn't want the sender to
check for any of these (may be the sender might want to do some simple
checking) but to check for anything important then I would let reciever do
this and return a structured response to acceptance of the message (pay
load).


HTH

Ollie
 
Back
Top