Sending One Bigger or Several Small Messages to a Reporting Service


I would like to ask for some help with deciding on what kind of message, what they should include, and how long they should be. It is sort of about message decomposition.

I am trying to build a case for separating/relaxing a reporting sql db from the production in a retail environment.

The case is about a client’s receipt being registered and based on many of those registered receipts a report is made every day about how many new customers, as well as if it were purchased from a store or online, and which articles were purchased.

Once every X minutes we get a list of multiple receipts (can be 1 or can be 100s), so I have a list of incoming receipts with all the data (where, who, how many, total sum, etc as one would see when you purchase something)

As a step 1 I would like to inform the reporting service about the following:

  • we have a new purcahse from store/online
  • if it is from a new customer or existing/member
  • there have been bought 1 x ArticleA, 3 x ArticleB, 2 x ArticleC
  • the total sum of each the receipt

While it is easy to send an event/messages like:

  • new purchase from an existing member
  • purchase total sum
  • a new customer registered

I am not sure if they should be like that or they could be combined messages so that the reporting service could create several records from one message (so that the reporting service could create several records from one message), for example:

  • new purchase from an existing member for a total sum of X
  • new purchase from a new member for a total sum of X

then as about the articles and amounts, should it be:

  • an ArticleId X purchased
  • an amount of N of ArticleIDs X purchased (could be from a single purchase or a result from multiple receipts coming every X minutes)

the thing about articles is that sometimes the list is going to be quite big for a message (let’s say you buy groceries for one week, then there could be a 100 or ArticleIds in the message). So, while I have some options about new/old customers’ messages or total sums, I do not know how to deal with the lists of purchased ArticleIds that need to be sent to the reporting service. It does not feel right to send long lists and at the same time, it does not feel right either to send 100 messages for each Article(Id) that was purchased, or is it OK to do that?

Any thoughts on that?



I would recommend considering which service(s) are actually taking part in this scenario and how the data from them should be composed. Answering those questions should lead naturally to your message design and the problem of how much data should and shouldn’t be on the messages will become more obvious. For messages which cross service boundaries, having them contain data is best avoided. Within a service boundary, it matters less how much data you put on a message, but it may be that a reporting component within that boundary can just go direct to a data store to retrieve the data, with messages acting more as triggers for something to be done, like sending a report.

For more information about identifying your services and their boundaries, and the best way to shape messages within and between those boundaries, I recommend my talk on the subject.

Thanks Adam for your reply.

In the example from the presentation, when there is (OrderId + Data) in the messages sent:

the Data part, would it come inside the message, or would it be the link to some storage/cache place?

I feel worried about the coupling that is introduced with the Data format? For example, the addresses to different countries could have different fields, formats of the zip codes, different required and non-required fields, and so on. How do things like this get handled? The sender and receiver sort of need to agree on the contract there, don’t they, even if it is JSON with some possibly missing or extra properties?