Stop Using “Real Time” Wrong

It has nothing to do with latency and it’s making your systems more complicated.

Control panel vector created by storyset

I’m fighting this ongoing war with the phrase “real time” at work. I want to eliminate it from our vocabulary — to the point where I periodically fantasize about standing up a Slack bot that auto replies to the phrase “real time” with “did you mean to define a clear SLO?”

The problem with the colloquial use of the phrase “real time” among most software engineers and the startups that employ them, is that it does not set a clear requirement. It is used to communicate the expectation of a quick response time (which is also not what it means … more on that later) but the most literal interpretation of that is impossible. Computer systems cannot process things instantaneously. There’s always some delay, maybe only milliseconds or nanoseconds.

Adding to the problem is how people perceive time. From the perspective of most users milliseconds is instantaneous. But so is the five second delay on live TV. From a technical perspective the difference between five milliseconds and five seconds is a completely different architecture.

For example, if it’s necessary for us to process data within milliseconds of it being created we probably don’t care about recovering the occasional dropped packet. Data that is actually that time sensitive tends to be completely useless when it shows up late, so we might not even bother with it.

If we need to process data within seconds of it being created we have to stream it, which is a different set of tools and sometimes means wrapping the data in a specific format that makes it easier to cut up and reassemble.

If we need to process data within minutes then we can batch it, which again is a different infrastructure. Batch processing is a lot easier to do than streaming, I personally do not want to support streaming if I don’t have to.

So describing things as “real time” just creates situations where everyone has a completely different idea of what we’re building and what it needs to be optimized for. Pointing this out to people almost always results in them switching to the even more useless phrase, “near real time”

“Near real time” is both as vague as “real time” with the added bonus of also…