Different kinds of message timestamps

A message, be it command or event, will often carry one or more timestamps that indicate when a particular action has taken place. A simplistic view gives a message a single timestamp but the reality is there are actually a number of timestamps that may apply to a message and conflating them all into a single value may have negative consequences.

For instance on a system I've worked with messages had a number of infrastructure level timestamps:

  • A creation timestamp which indicated the time the message was created in code. This generally corresponds to the time the business logic that created it was run.
  • A publishing timestamp which gave the time the message placed into the message hub and hence became visible to the rest of the system. Under heavy load this is potentially hours after the creation of a message.
  • A causation timestamp that gave the creation time of the message that caused the creation of the current message (where relevant). Under load this may be hours before the creation timestamp.

These different infrastructure level timestamps are necessary to track latencies in asynchronous message processing. Some systems may require additional timestamps to cover how they process messages. Synchronous systems may also require multiple timestamps to track how long operations take.

In addition to infrastructure level timestamps messages will often require business level timestamps. An infrastructure timestamp is an implementation detail of the system used in management, debugging and optimisation. These will generally not coincide with the timestamps that the business wants to associate with business events, and where they do this association is only coincidental. Infrastructure timestamps are also subject to change due to different factors than would affect business logic.

For instance a business may make a service available at various plan levels. Customers may modify their plan level which will take effect on the next business cycle which starts at midnight in the head office timezone. It is not feasible to process potentially many thousands or tens of thousands of plan changes at exactly midnight. Instead the business may choose to pre or post process the requests (even by a few minutes). In order for the change to appear at the correct time a business level timestamp is applied to the message giving the time the business considers the plan to have changed.

Depending on implementation this may mean that the plan changeover happens for the customer slightly before or after midnight but if appropriately consulted this may be completely acceptable to the business.

What this implies is that if you have any business logic that depends on timestamps or you need to display information to end users that information should in almost all cases come from business timestamps that have been explicitly modelled. As this requires you to explicitly model the timestamps you will need it has the advantage that it forces you to explicitly consider time related issues in your domain. Particularly for financial calculations this can be very important in how you handle data.

In summary:

  • Multiple infrastructure timestamps are very useful for building and running the system.
  • Any timestamp that is of interest to the business should be explicitly modeled.
  • Do not expose infrastructure timestamps to end users or use them in business logic.

Colin Scott

Read more posts by this author.