Distributed Transactions in Track & Trace

Introduction

Track & Trace systems rarely operate as a single application.

A typical shipment can involve a warehouse system, an enterprise Track & Trace platform, and an external regulatory system.

Each system has its own responsibility and its own state.

This becomes challenging when one part of the process succeeds while another part fails.

A Simple Track & Trace Scenario

Consider a shipment moving from Warehouse A to Warehouse B.

The warehouse completes the shipping operation, and the Track & Trace platform records the shipment as SHIPPED.

As part of the same process, the platform creates an EPCIS event representing the shipping operation.

The event is then sent to the external regulatory system.

Under normal conditions, everything works as expected.

The problem starts when the regulatory system is unavailable.

When the Regulatory Submission Fails

Imagine that the shipment has already been recorded as SHIPPED, but the regulatory API returns an error or the request times out.

At this point, the internal system knows that the shipment was shipped, but it does not know whether the regulatory system received the event.

The two systems now have different states.

The internal system says:

Shipment = SHIPPED

The regulatory submission says:

Status = UNKNOWN

This is a distributed transaction problem.

Why a Traditional Rollback Does Not Work

The first idea might be to rollback the shipment.

But this does not necessarily represent reality.

The products may have already left the warehouse.

Changing the database status back to READY does not move the products back to the warehouse.

For this reason, the operational state of the shipment should be treated separately from the regulatory submission state.

For example:

Shipment Status = SHIPPED

Regulatory Status = PENDING

The shipment remains shipped, while the failed regulatory submission can be processed independently.

EPCIS Event Handling

The Track & Trace platform can create an EPCIS event for the shipping operation.

The event can contain information such as the serialized product, the event time, the business step, and the relevant location.

The important part is that the EPCIS event represents the business operation that actually happened.

The availability of the external regulatory system should not change the fact that the shipment took place.

Retry and Idempotency

Once the regulatory system becomes available again, the failed event can be retried.

However, retries introduce another problem.

A timeout does not always mean that the external system did not receive the request.

The regulatory system may have processed the event successfully, while the response was lost because of a network problem.

If the Track & Trace platform sends the same event again, the regulatory system may receive a duplicate.

This is where idempotency becomes important.

The integration should be able to recognize the same business event when it is retried and prevent it from being processed more than once.

Reconciliation

Retrying is not always enough.

There may be cases where the internal system and the external regulatory system have different information about the same shipment.

For example, the internal system may show the shipment as successfully processed, while the regulatory system does not have the corresponding event.

A reconciliation process can identify these differences and help determine what needs to be corrected.

This is particularly important in Track & Trace because the history of the product and its events must remain consistent across the ecosystem.

Designing for Failure

A reliable Track & Trace integration should assume that failures will happen.

Network failures, timeouts, unavailable services, validation errors, and unexpected responses are all possible when communicating with external systems.

Instead of trying to make the entire operation one atomic transaction, the system can use asynchronous processing and keep track of the state of each operation.

This allows the system to retry failed events, detect duplicate submissions, and reconcile situations where the final result is unknown.

Conclusion

Distributed transactions are a natural challenge in Track & Trace because the ecosystem is made up of multiple independent systems.

A shipment can succeed operationally while its regulatory notification fails.

The solution is not always to rollback the shipment.

A better approach is to preserve the actual business state and handle the regulatory submission separately through reliable retry mechanisms, idempotency, and reconciliation.

This approach allows Track & Trace systems to remain consistent and recoverable even when one part of the ecosystem is temporarily unavailable.