A couple of events over the last week have me thinking about the concept of aliasing. I first encountered this idea when I started messing with computer graphics back in the late 80’s, and indeed the first event to which I refer involved someone on a forum bringing up the use of “antialiasing” techniques in games and other graphical applications. The term aliasing in general means a loss of information. In graphics people use the word aliasing to mean the jagged lines that result from rendering continuous geometrical features to a pixelated frame buffer. The reason that you see jagged edges on lines and polygons is because information has been lost where there is no pixel to hold it.

The second case that arose also involved a loss of information, but it was less obvious to the people working on it. In this instance a system produces changes to a database, and each change triggers a message out to an enterprise service buss. The problem is that the messages are unordered, and often involve sequential changes to the same field in a record. The designers created a multi-threaded sender for the resulting messages, and cannot guarantee the order of receipt, nor did they provide for any closure message to signal the end of a transaction. Given such constraints, can the state of the entity from the view of message consumers ever be guaranteed to be consistent with the state as seen by the publisher?

The answer is no. In this case, as in the aliasing of edges in a rendered image, information has been lost that cannot be replaced by the target system. In the graphical image it was the color of the missing pixels. Here it is the order of changes to an entity. Once that data is gone, it’s gone. Graphical applications can compensate to some extent by making assumptions. For example, they might assume that the color of a pixel neighboring two other pixels in a jagged line should be set to an average of the surrounding pixels, thus filling in some of the missing information with a best-guess at what might have been there. This is in fact how graphical anti-aliasing works, and it can produce dramatic improvements.

There are similar techniques for sound, although less successful because sound is less forgiving of error. Business information is less forgiving still. If a bank account is supposed to go through a series of transformations leaving it with a balance of x, there is no way to guess what x should be if some of those changes are applied in the wrong order. How could we fix the underlying problem in this particular design? The only way is to provide enough information to consumers to allow them to reconstruct the order of changes. But really the issue is the basic design: the object should not have been published to observers of the transaction on the buss until it was in a consistent and stable state.  Lacking either of these remedies there is nothing clients can do to restore the missing information and guarantee integrity. Ultimately it’s no different than running a pristine digital image through a lossy compression algorithm: you’re throwing stuff away, and you can’t get it back.