Offline Handling in Pharma Track & Trace Architecture

Offline Handling in Pharma Track & Trace Architecture

In pharma track and trace, we spend a lot of time designing for the connected state: fast networks, responsive portals, real-time event reporting. But the question that separates a robust architecture from a fragile one is simpler than that: What happens when the network drops?

Ahmed Gamal · Origin Technology June 11, 2026 2 min read 6 views

In pharma track and trace, we spend a lot of time designing for the connected state: fast networks, responsive portals, real-time event reporting. But the question that separates a robust architecture from a fragile one is simpler than that:

What happens when the network drops?

The reality on the factory floor

Packaging lines don't pause for connectivity issues. A line running at full speed will continue aggregating, commissioning, and shipping, with or without a live connection to the regulatory portal. If your architecture wasn't designed for this, you will face one of two outcomes: either the line stops, or the data gets lost.

Neither is acceptable in a regulated environment.

Three failure modes nobody plans for

  1. Silent data loss: Events are generated but never queued locally. When connectivity resumes, there is no record of what happened during the outage. This is the worst outcome: you don't know what you don't know.
  2. Duplicate reporting on reconnect: Retry logic without deduplication sends the same events multiple times. Regulatory portals reject duplicates, and reconciliation becomes a manual nightmare.
  3. Broken sequence on replay: EPCIS events have strict ordering requirements. If events are replayed out of sequence after a reconnect, the portal rejects the entire batch.

The architecture that handles it

A resilient offline design has three layers:

  • A local buffer that captures every event the moment it is generated, regardless of connectivity
  • A sync engine that detects reconnection, replays events in the correct sequence, and handles deduplication
  • A reconciliation mechanism that compares local state against portal state after recovery and flags any gaps

The happy path is easy to build. The offline path is where the architecture earns its reliability.


The design principle that matters

Never assume connectivity. Design every component as if it will run disconnected, and treat the online state as a bonus, not a requirement.


In pharma T&T, a system that gracefully survives a network drop is not an edge case. It is a production requirement.


Prepared by: Ahmed Gamal - Engineering Director & Solutions Architect Origin Technology