I am not a software engineer, but most of the time the semi-technical background I have is enough to make accurate inferences in technical product conversations. Sometimes though, I run into a term whose connotation in plain English gets in the way. Here are three of those terms I’ve come across recently and what they really mean.

1. Lossy Compression

The alternative here is lossless compression which, especially in the world of video entertainment, sounds better at first. People want high-quality visual experiences - why would we want our video encoding to be lossy when it could be loss less?

It turns out, pretty much any streaming video you watch (YouTube, Netflix, Twitch, etc.), and most video files you download, are compressed using lossy compression.

Video is encoded in frames. Each frame of a video compressed with lossless compression will contain a full image that perfectly matches the one from the uncompressed video. The file is compressed by removing non-image data or finding simpler ways to describe all of the image data that needs to be sent which, while it does reduce the file size significantly, doesn’t reduce it enough to stream video on most connections.

With lossy compression, only some of the frames will exactly match those from the uncompressed video; those in the interim carry information about which parts of the last full-frame change noticeably in the next frame and in what way. This type of encoding allows a much smaller amount of data to show the same length of video which reduces latency and dependence on perfect network conditions.

It comes down to an ever-important principle: increases in performance and quality matter deeply - but only when people notice them. People notice lag when viewing a stream a lot more readily than they notice a few frames of slightly less crisp background.

2. Unreliable Data Channels

This plays off similar principles. Reliable data channels are so named because they make sure that each packet of data is sent and received in the perfect order, signaling “Hey we just sent a little something,” “Did you get it?,” ‘‘I’ll resend it,” ‘‘How about now?” Which, as you might imagine, isn’t the fastest way to send data.

In video streaming (especially interactive video streaming) it is essential that we send new data fast to maintain something that feels live and native, much more than making sure each little packet of data is sent and received perfectly. This is why we use unreliable data channels.

A little bonus tip for those of you who, like me, constantly feel like you’re drowning in acronyms: TCP provides reliable data transfer, UDP provides unreliable (but faster) data transfer. You’re welcome.

3. Zero-Trust Security

This one isn’t specific to interactive streaming, but it is a principle I have come across a few times as we move into the enterprise space. If I were better steeped in security discourse, I might more readily associate trust with risk and not have been so prone to misinterpret the name of this concept. However, coming from the user side of things, I am used to trust as a positive, so zero-trust sounds kind of like a bad thing.

Zero-trust is an approach to IT security coined by computer scientist Dr. Stephen Paul Marsh. A zero-trust model involves a number of principles and practices, but, in essence, it just means no previous or existing access or permission is going to automatically afford a device or application further access or permission.

The alternative is what’s called “castle-and-moat” security, which is where it’s hard to gain access to a network, but once you’re in you have access to everything.This made more sense when organizational IT was centralized, but now, with more data in more places, there is an increasing trend towards zero-trust architecture. This is because, while it might be slightly less convenient to have to log in and request permissions more often, it is a lot better than a security breach.


Learning individual terms can be helpful, but what I find more useful is starting to recognize patterns and their meaning. The terms I mentioned here can be misleading because the concepts are named for what they lack. When it comes to engineering though, we necessarily choose to forgo certain capabilities to focus on the types of performance that matter for our specific use case. Identifying new areas where that’s possible is one of the ways we innovate.

If you love what you’ve read, keep an eye out for more posts (including further breakdowns of tech terms).