Skip to main content
Back to insights

Define Data Freshness Explicitly

A value may be accurate when captured and misleading when used hours later. Teams need to know how old a reading or status may be for a specific decision.

  • Architecture
  • Integration

Arinao Tshamano14 October 20262 min read

A value may be accurate when captured and misleading when used hours later. Teams need to know how old a reading or status may be for a specific decision. Inventory shown as available may be useful for a daily planning report but unsafe for a promise made to a customer minutes later. Freshness is a property of the decision, not just the database. State when the value was observed and what happens when it exceeds its allowed age.

What good engineering looks like

What maximum age is acceptable at the point where the user or process acts? Answer this for a named workflow and an accountable team. Identify the information needed at the moment of decision, the system that can settle a dispute, and the route for correcting dependent copies. The technical design should make those business rules visible to the people who operate and support the handoff.

  • Identify the decision and the source update frequency.

  • Display observation time and set a freshness threshold.

  • Choose whether stale data blocks, warns or triggers a refresh.

  • A named owner for a rejected, delayed or repeated item.

  • Evidence that the receiving system applied the intended business state.

A practical starting point

  1. Choose one real case and write down its trigger, expected outcome and responsible team.

  2. Present a stale value to a user and to an automated consumer.

  3. Confirm that each can recognise its age and follow an agreed fallback, refresh or pause route. Measure end-to-end delay through the real handoff, including queues and batch windows, rather than relying only on source timestamps.

  4. Record what the test exposed, who will resolve each open question and how the fix will be checked.

Keep the first design small enough to review with the people who run the process. Test an exception alongside the normal case. A successful transport test shows that data moved; it does not by itself prove that the receiving team can make the right decision or recover from a partial failure.

The decision to make

Real time delivery is not automatically better. Set freshness from operational risk and cost, then monitor it. Decide what level of timing, traceability and recovery this workflow actually needs. Document assumptions that remain untested and revisit the choice when a partner, process or business rule changes. The point is a dependable operating decision, not simply a working interface.

Explore Algoza's related services: https://algoza.co.za/services/integration

Apply the thinking

Working through a related technology decision?

Share the operational context, current systems, constraints, and decision you need to make.

Discuss a requirement