While this is not an issue often discussed, ignoring it can lead to serious issues that will typically surface during integration or performance testing.

We refer to message affinity as a situation that occurs when a system issues a series of inter-dependent transactions, which are issued in a short period of time. Because each transaction is issued separately, they are subject to be processed in a different order than when they are issued by the client.

The result may be unpredictable, as the following example shows. To make it concrete, let's look at an Order process that would issue three separate transactions, as shown in the following diagram:

Because the Service Provider is multi-threaded, the order of processing can vary depending on the load at the time. A potential result is illustrated in the following diagram:

The first item being processed out of order would be rejected because the order object hasn't been created yet. However, the two subsequent objects would succeed and leave the system in a state where the order is recorded as having a single item instead of two.

The challenge with this situation is that it is hard to troubleshoot. An unaware developer may not be able to reproduce this behavior on his/her development platform.

Now, you may be wondering, how does that relate to blockchain and Hyperledger Fabric? Considering that Fabric transactions are asynchronously processed and that they are validated against every world state, this situation can arise. The client will issue the transaction and may asynchronously receive a message saying that the transaction was invalid because it did not correspond to the world state.

The moral of the story here is that when designing an API, make sure that they are at a granularity level that completely describes a business event. Too many fine-grained transactions only leads to message affinity, increased latency, and the potential for issues, as described here.