How Instagram Reduced Video Processing Compute by 94%
I always wondered how Instagram actually saves all those endless videos people upload every single day.
I know people who upload at least 2–4 videos daily. And if we think about the total number of active Instagram users, we're talking about billions of people.
So, you can do the math.
Actually, I can't even think of what that number would look like. It's that big.
This made me wonder: How big are Instagram's data centers?
I'm sure they have multiple data centers because one data center, regardless of how big it is, couldn't possibly handle all that data on its own.
So, I did a little browsing and came across an article from Meta's engineering team explaining how they managed to reduce the compute time required for Instagram's video processing by 94%.
Yeah, you read that right.
94%.
That reduction helped them process videos much more efficiently while freeing up compute resources for more advanced video encodings.
But what exactly was the issue? Why did they need to do this? And what was actually going wrong?
It Started With a Pretty Serious Problem
Back in early 2021, Meta engineers realized that they had roughly one year of compute capacity left for Instagram's video workloads.
Yes, you read that right again.
At their existing growth rate, they were running out of available compute capacity.
And why was this such a big problem?
Well, imagine Instagram without the ability to efficiently process all the videos people upload.
We might end up back in the good old Instagram days when people mostly shared pictures, and we had that notification panel that literally told us what other people were doing.
That gives me some serious nostalgia.
Those were the days. Wow.
Okay, okay. Let's not drift away from our main topic.
So, What Was Actually Happening?
Whenever someone uploaded a video to Instagram, Instagram generated different versions of that video.
One of them was ABR (Adaptive Bitrate) encoding.
You've probably experienced how ABR works without even realizing it.
Imagine you're watching a Reel on Instagram and suddenly your internet connection gets worse.
Instead of completely stopping the video, Instagram can automatically switch to a lower-quality version of that video.
When your connection improves, it can switch back to a higher-quality version.
That's essentially the idea behind adaptive bitrate streaming.
The second format Instagram generated was called Progressive encoding.
Progressive encodings were mainly required to support older versions of the Instagram app and other clients that didn't support ABR playback.
So Instagram was effectively spending compute resources generating both ABR and Progressive encodings.
And that's where things started getting expensive.
The Compute Problem
Converting and saving videos in both formats required a significant amount of compute.
To be precise, processing one video through this encoding pipeline could take around 86 seconds of CPU time.
Now imagine doing that for the massive number of videos uploaded to Instagram every day.
That's a lot of CPU time.
So Meta engineers started thinking about possible solutions.
And the obvious solution would be:
"Okay, let's just build another data center."
Easy, right?
That's what I thought too.
Meta has the money. Why don't they just open another data center?
So I casually Googled:
"How much does it cost to build a data center?"
I dare you to Google that question.
Once you do, you'll probably come back to this article and continue reading it with a finger on your lips. 😶
Instead of Adding More Compute, They Reduced the Work
Obviously, building another data center every time they needed more compute wasn't going to be the best long-term solution.
So what else could they do?
They dug deeper into the existing video-processing system and realized that the solution might already be sitting right in front of them.
They noticed that the settings used for the two types of encodings were quite similar.
Both used the same codec, with only relatively small differences in their encoding profiles and presets.
That led to an interesting idea.
Instead of separately generating the basic ABR encodings, they could reuse the already-generated Progressive video frames and repackage them into an ABR-compatible file structure.
In simple terms:
Old approach:
Upload video → Generate Progressive encoding → Generate basic ABR encoding separately → Generate advanced ABR encodings
New approach:
Upload video → Generate Progressive encoding → Reuse those encoded frames for basic ABR → Generate advanced ABR encodings
They essentially stopped doing some of the same expensive work twice.
And that eliminated most of the compute cost required to generate the basic ABR encodings.
But There Was a Trade-Off
The diagram above shows how this approach worked before and after the change.
The new approach freed up a significant amount of compute capacity that could now be used to produce more advanced encodings.
But, as we know, almost every engineering decision comes with trade-offs.
The downside was that reusing the Progressive encoding came at the expense of some compression efficiency for the basic ABR encodings.
Meta's theory was that this trade-off would still be worth it.
Why?
Because the compute they saved could be used to generate more advanced encodings for more videos.
Those advanced encodings could provide better playback experiences, potentially increasing the amount of time people spent watching videos.
So even if the basic ABR encoding became slightly less efficient, the overall experience could still improve.
But having a theory is one thing.
Pushing it to production is something completely different.
You Don't Just Push a Change Like This to Billions of Users
Developing or fixing something is one thing.
Deploying that change to a platform as large as Instagram is another.
When you have billions of users on your platform, even a tiny mistake can become a massive problem.
So Meta couldn't simply say:
"Looks good. Ship it."
They needed to test whether their theory actually worked in the real world.
To measure the impact, they built a testing framework that replicated a small percentage of traffic across two environments:
A test pool
A control pool
Both pools had equal processing power.
They saved the encodings produced by each pool into separate namespaces so they could later identify whether a video belonged to the test or control catalog.
Then, when videos were delivered to users, each person would receive encodings from only one catalog or the other.
This allowed Meta to compare the two approaches and answer the important question:
Does the new encoding strategy actually provide a better overall experience?
And the Experiment Worked
The test showed something interesting.
Even though the compression efficiency of the basic ABR encodings decreased, the increase in advanced encodings helped compensate for that trade-off.
The result was increased watch time for advanced encodings.
Once Meta had enough evidence that the approach worked, they rolled it out to production.
And that's when they saw the major gains:
Significant compute savings, more advanced video encodings, and increased watch time on those advanced encodings.
The most fascinating part to me is that their solution wasn't simply:
"We need more servers."
Instead, they looked at the work their existing servers were doing and asked:
"Do we actually need to do all of this work twice?"
By reusing already-encoded video frames instead of independently generating another set of basic ABR encodings, they dramatically reduced the compute required for that part of the pipeline.
And that's a great system-design lesson.
Before throwing more hardware at a scaling problem, sometimes it's worth asking whether you can simply do less work.
If you want to read Meta's original engineering article, you can check it out here:
And if you enjoy learning about interesting engineering problems like this, you can follow me for more.
