Transaction Tracking vs Transaction Tracing – What’s the Difference?

Transaction tracking and tracing are not the same thing.

One of the top 10 banks in the world recently chose meshIQ and this was their primary reason.

They had a Priority 1 request processor incident on the mainframe where high value messages went missing and it took two weeks to find them.

They began by looking at another vendor who said that they did transaction tracking. As the customer said, “They will try to tell you that they do transaction tracking, and that took us a while to drill down.”

So, let me explain the difference between these terms using an analogy.

Imagine a bridge with cars going over it.

Tracking:

Pick one car and follow it all the way from one side of the bridge to the other.

Tracing:

Pick a fixed point on the bridge and record all the cars that go across that point.

Tracing is essentially logging of the function calls in an application and the underlying technologies on a single server. In a trace you can see the user accessing the application, then the application calling the database and the middleware and the operating system, but it’s all in one location.

So, whereas tracing is looking at all the activity in one location, tracking is looking at a particular activity on a particular piece of data (the transaction) across all locations.

Tracking can be achieved using the tracing data. You can put all the tracing data from all the locations into a big data analytics platform or data lake and find all the parts relating to the particular transaction and stitch them together to show the journey of that particular transaction. So in this sense, tracing is a component of tracking but tracking is a lot more.

This particular company’s Audit Department had highlighted a compliance requirement that a message isn’t changed while in the hands of the bank. So they needed a snapshot (trace) of it when it enters the middleware and also when it leaves (another trace) so that they have assurance that, for example, the amount, or the payee hasn’t been changed en-route. To achieve this they needed tracking. They now use meshIQ to analyze and compare the transaction at every step and compare it at each step with itself as well as with historical performance of similar transactions to identify and alert on anomalies.

Hopefully it’s now clear that tracking is so much more than tracing. The trace data is needed too, so that you can do a real deep dive into what happened at the location for root cause analytics and remediation. High level observability isn’t enough but that’s a whole separate discussion.

You can read more about meshIQ’s transaction tracking capabilities here.