DEV Community

NARESH
NARESH

Posted on

Why Instagram Reels Feels Different From YouTube Shorts: An Engineering Look at Recommendation Systems

Blog Banner

The observation that started this rabbit hole

Have you ever watched a few Instagram Reels about something completely random, then opened the app later and wondered, “How did my feed become this specific?”

That kept happening to me.

If I watched a few anime Reels, Instagram would quickly start surrounding me with related content. Not necessarily the exact same video. I might watch a clip of Goku turning Super Saiyan, then get another Dragon Ball scene, an edit from a different creator, a related fight, or something from the same anime universe.

YouTube Shorts felt different.

When I repeatedly watched Shorts from a particular creator, that creator seemed to keep returning. Sometimes I would even encounter very similar clips uploaded by different channels. It felt less like my feed was chasing the topic I cared about at that moment and more like YouTube was leaning on what it already knew I enjoyed.

At first, my conclusion was simple:

Maybe Instagram just has a better recommendation system.

But “better” is a dangerous word in engineering.

Both companies operate recommendation systems at enormous scale, backed by sophisticated retrieval, ranking, machine learning, and infrastructure. So I started looking through Meta’s engineering publications, Google research papers, and YouTube’s own documentation.

What I found was more interesting than one algorithm being better than another.

The two systems share surprisingly similar foundations. The difference seems to emerge from the signals they trust, how quickly those signals matter, what they optimize for, and several engineering decisions hidden behind the feed.

That is what this article is about.


Before comparing them, one architectural constraint matters

At the scale of Instagram and YouTube, recommendation starts with a fairly brutal engineering constraint.

There may be millions, or even billions, of pieces of content that could theoretically be shown to a user. Running the most powerful ranking model against every one of them whenever someone opens the app would be an extremely expensive way to build the system.

You could throw more compute at the problem, but the user is waiting for the next Reel or Short now. Recommendation systems live under tight latency budgets, so spending heavy neural network inference on obviously irrelevant content makes little sense.

This is why both systems are built as a funnel.

Recommendation Funnel

Start with multiple candidate sources

The system does not usually search for recommendations from one giant homogeneous pool.

Different retrieval sources may represent different kinds of opportunities:

  • content related to your recent interests
  • creators or channels you have interacted with
  • historically relevant topics
  • trending or fresh content
  • exploration candidates the system wants to test

Each source is trying to answer a broad question:

Is there any reasonable chance this user might care about this item?

At this point, recall matters more than perfect ordering. Throwing away a great candidate too early means no downstream model can recover it.

Retrieval: reduce the search space cheaply

Retrieval is the first major reduction.

Embedding-based systems are especially useful here. In a simplified Two-Tower design, one neural network produces a representation of the user from signals such as watch history, recent interactions, or context. Another produces representations for media items using information about the content and its behavior.

The resulting vectors make it possible to search for items that are mathematically close to the user’s current representation.

The important optimization is that the system does not deeply evaluate every video. It performs a much cheaper search over a representation space and reduces an enormous corpus to perhaps thousands of plausible candidates.

Think of retrieval as:

Find everything that might deserve a closer look.

Merge: turn several retrieval paths into one candidate set

Those candidates may have arrived from several sources.

Before ranking them seriously, the system needs to combine them.

This stage can remove duplicates, balance candidate sources, and stop one retrieval strategy from completely dominating the pool.

For example, if every retrieval source independently discovers the same highly popular video, carrying several copies of it further down the pipeline wastes compute.

By the end of this stage, the system has one cleaner candidate set ready for ranking.

First-stage ranking: be selective without being expensive

Now the system knows these candidates are at least plausible.

But there may still be thousands of them.

Running the largest ranking model on all of them is still expensive, so a lightweight ranker acts as another filter.

It uses relatively inexpensive features and fast scoring to remove weaker candidates.

This model does not need to make the final decision. Its responsibility is closer to:

Which of these candidates are worth spending serious computation on?

This can reduce thousands of candidates to hundreds.

Second-stage ranking: spend compute where it matters

Only now does it become economically reasonable to use a much heavier model.

Because the candidate set is small, the ranker can consider richer information about both the user and the content.

Instead of predicting a single notion of relevance, it may estimate several outcomes:

Will the user watch?
Will they finish?
Will they like or share it?
Will they skip quickly?
Will they find it satisfying?
Enter fullscreen mode Exit fullscreen mode

These are multi-objective decisions.

A video that has a high chance of being clicked or watched is not necessarily the best recommendation if it also has a high probability of being skipped, disliked, or producing poor long-term satisfaction.

This is where ranking becomes much more than sorting videos by similarity.

Re-ranking: the highest score does not automatically win

Even after the heavy ranker produces its scores, the system may still modify the final ordering.

Suppose the top ten predictions all come from the same creator, contain nearly identical clips, or repeatedly cover the same topic.

A mathematically accurate ranking could still produce a terrible feed.

Re-ranking gives the product another layer of control over things such as diversity, freshness, safety, originality, policy, and exploration.

Only after this stage do we get the final personalized feed.

Then the loop begins again.

You watch, skip, like, share, search, or leave. Those actions become new evidence that can influence future requests.

So the architecture is really a sequence of increasingly expensive questions:

Retrieval
Could this be relevant?
Enter fullscreen mode Exit fullscreen mode
First-stage ranking
Is this candidate worth deeper evaluation?
Enter fullscreen mode Exit fullscreen mode
Second-stage ranking
How valuable is this recommendation likely to be?
Enter fullscreen mode Exit fullscreen mode
Re-ranking
Should it actually appear in the final feed?
Enter fullscreen mode Exit fullscreen mode

This funnel is the common foundation underneath both Instagram Reels and YouTube Shorts.

The interesting difference starts after that foundation.

Both companies can build sophisticated retrieval and ranking models. What changes the experience is what signals they feed into those models, how quickly those signals change, and what the system ultimately considers a successful recommendation.


The first surprise: the architectures are more similar than they look

Before looking at the research, I expected Instagram and YouTube to have noticeably different recommendation architectures.

That was not really the case.

Meta’s published recommendation systems and Google’s YouTube research both describe variations of the same fundamental pattern we just saw: retrieve a broad set of plausible content, progressively rank it with more expensive models, then apply additional logic before deciding what reaches the user.

The models have evolved significantly over the years, and the exact production systems behind Reels and Shorts are not publicly exposed. Still, at the system-design level, both companies are solving the same constraints:

Huge content corpus
        ↓
Find plausible candidates quickly
        ↓
Spend more compute on fewer candidates
        ↓
Predict several possible user reactions
        ↓
Construct the final feed
Enter fullscreen mode Exit fullscreen mode

That changed the question for me.

If both platforms have access to sophisticated retrieval, embeddings, neural ranking, massive infrastructure, and years of interaction data, then Instagram feeling different cannot be explained by saying its model is simply more advanced.

The difference has to emerge somewhere else.

Three areas started to matter much more:

Signals: What does each platform know about the user?

Freshness: How quickly can a new interaction influence the next recommendation?

Objective: What behavior is the system ultimately trying to optimize?

Those choices can make two systems built on very similar foundations produce noticeably different feeds.

And this is where Instagram starts to become particularly interesting.


Instagram’s interesting advantage is not simply better AI

The first useful clue came from how Meta handles candidate retrieval.

In its published architecture for Instagram Explore, Meta describes using multiple retrieval sources at the same time. Some are pre-generated and capture longer-term interests. Others operate in real time and are designed to capture recent interactions.

That distinction matters.

Suppose most of my Instagram history says I care about software engineering, football, and technology. Then, during one evening, I watch several Dragon Ball clips almost completely, like one of them, and save another.

Instagram does not need to retrain a neural network specifically for me.

Fresh interaction signals can change the information used during the next recommendation request. Meta also describes retrieving content directly from a user’s interaction history by finding items similar to things they recently liked, saved, or shared.

Conceptually, the system can do something like:

Recently watched Dragon Ball Reel
             ↓
     Content representation
             ↓
 Find related candidate content
             ↓
 Add those candidates to the pool
             ↓
           Ranking
Enter fullscreen mode Exit fullscreen mode

This mechanism is publicly documented for Explore, so I would not claim that Instagram Reels uses the exact same implementation. But it shows that Meta’s recommendation infrastructure is explicitly designed to combine persistent interests with much fresher behavioral signals.

There is another detail that may explain something I had noticed for a long time.

When I watched anime content on Instagram, I often received related clips from different creators, but rarely the exact same clip reposted again and again.

That is not entirely accidental.

Instagram says that when it detects multiple identical pieces of recommended content, using audio and visual matching, it tries to recommend the original instead of the repost. This policy applies to Reels, Explore, and recommended Feed content. Materially changed versions, such as reactions, remixes, memes, or new voiceovers, can still remain eligible.

That creates an interesting product effect.

If I watch Goku turning Super Saiyan, the system does not necessarily have to keep showing five copies of that transformation. It can move around the same interest space:

Goku transforms
      ↓
Goku vs Frieza
      ↓
another Dragon Ball edit
      ↓
related anime content
Enter fullscreen mode Exit fullscreen mode

From the user’s perspective, this can feel like the system understood the topic rather than merely memorizing the video.

That distinction is important.

Perceived recommendation quality does not come only from having a more powerful ranking model. Candidate freshness, duplicate handling, source diversity, and how broadly the system explores an interest can change the experience before the final ranking model even gets a chance to make its decision.


YouTube has a different kind of memory

YouTube becomes interesting for almost the opposite reason.

Its recommendation system is not limited to what you just watched in Shorts. YouTube publicly documents that recommendations can use watch history, search history, channels you enjoy, subscriptions, likes, dislikes, and satisfaction signals. It also learns across formats such as Shorts, long-form video, live streams, and posts.

That creates a much deeper historical profile.

If I watch several Shorts from one creator, YouTube has a strong reason to keep that creator in the candidate pool. The system is not only learning that I liked a topic. It is also learning that I seem to trust or enjoy a particular channel.

Conceptually:

Short from Creator A
      ↓
High watch / engagement
      ↓
Creator affinity increases
      ↓
More content from Creator A
becomes competitive in retrieval and ranking
Enter fullscreen mode Exit fullscreen mode

This matches something I noticed personally. Once I start watching Shorts from a specific channel, that channel tends to keep resurfacing much more consistently.

But YouTube has another advantage that Instagram does not have in quite the same form.

A user might watch a 20-second Short about transformers, search for attention mechanisms, spend 40 minutes on a technical lecture, subscribe to an ML channel, and later watch another related Short.

Those interactions happen at very different depths, but they all contribute evidence about the same person.

A long-form video can reveal something a short interaction cannot: sustained intent.

Watching three 15-second clips about a topic might mean curiosity. Spending an hour on the same subject is a much stronger signal.

YouTube also explicitly talks about optimizing for long-term viewer satisfaction, not just immediate watch time. Signals such as survey responses, dislikes, and “Not interested” feedback help distinguish content that merely captures attention from content users actually value.

This makes YouTube’s recommender feel less like a system that only asks:

What should I show you next?

and more like one that also has to consider:

What kind of content relationship am I building with you over time?

That does not mean YouTube is less capable of reacting quickly. It means it has a much larger body of historical evidence competing with the latest few interactions.

And that leads to the question that changed this entire comparison.


The question I originally asked was slightly wrong

At the beginning, I was asking a simple question:

Why does Instagram’s recommendation system feel better than YouTube Shorts?

After looking at the architecture, that question started to feel incomplete.

What I was really noticing was not necessarily better recommendation quality. I was noticing how visibly the feed reacted to my current interest.

Those are different things.

A recommender can optimize for several goals at once:

  • immediate relevance
  • long-term satisfaction
  • diversity
  • creator discovery
  • freshness
  • retention
  • recommendation stability

A system that reacts aggressively to the last five things I watched may feel incredibly intelligent during that session.

It can also be wrong.

If I suddenly watch several Formula 1 clips tonight, should the platform immediately rebuild my feed around F1? Or should it treat that behavior as temporary curiosity while preserving the interests it has learned over months?

There is no universally correct answer.

That is a product decision expressed through ranking objectives, feature freshness, candidate sources, and weighting between recent and historical behavior.

So the more useful question became:

Why does Instagram make changes in my immediate interests feel more visible, while YouTube often feels more anchored to my broader viewing history?

That question gives us something much more interesting to investigate than simply declaring one algorithm better than the other.


The infrastructure detail I did not expect: move expensive work away from peak traffic

One line in Meta’s Explore engineering write-up caught my attention:

Applying a much heavier MTML model during peak hours could be tricky.

Their solution was surprisingly practical. For some users, Meta precomputes recommendations during off-peak hours so that expensive inference does not always have to happen while the user is waiting.

This is a classic production-engineering trade-off.

The most accurate model may also be the most computationally expensive one. If millions of users arrive at roughly the same time, running that model synchronously for every request can create unnecessary latency and infrastructure cost.

Instead of asking:

How do we make the heavy model infinitely faster?

the architecture can ask:

Which parts of this computation can safely happen before the request arrives?

Conceptually, the design looks like this:

Precomputation Design

Meta publicly confirms the precomputation strategy, but does not expose enough detail for us to claim exactly whether every cached object is a candidate set, ranking score, final list, or some combination of them.

That uncertainty does not reduce the engineering lesson.

This pattern appears everywhere in large systems. Search engines build indexes before queries arrive. Databases use materialized views. Recommendation systems precompute embeddings and candidate information. Applications warm caches before predictable traffic spikes.

The principle is the same:

Do not spend request-time compute on work that does not require request-time information.

Of course, recommendation introduces another problem: freshness.

A result calculated earlier may not know that the user suddenly spent the last ten minutes watching Formula 1.

So precomputation cannot blindly replace real-time personalization. The system has to decide which information is stable enough to prepare ahead of time and which signals must remain fresh.

That tension between accuracy, freshness, cost, and latency is one of the most interesting system-design decisions hiding behind what feels like an instant swipe.


The creepy recommendation problem: did Instagram hear me?

Almost everyone has had some version of this experience.

You talk to a friend about a show, a product, or a random topic, then a few hours later something closely related appears in your feed. The immediate reaction is obvious: the app must have heard me.

For ordinary personal chats on WhatsApp, that explanation does not fit how the system is publicly described. Message content is end-to-end encrypted, so Meta does not have a normal path where it reads a private conversation, extracts a keyword, and feeds that directly into Instagram ranking.

The more interesting explanation is that recommendation systems often do not need that information.

If you and your friend are talking about One Piece, several other signals may already point in the same direction. The topic may be trending, you may have interacted with anime before, your friend may be engaging with related content inside Instagram, or more creators may suddenly be publishing similar clips.

Instagram also has social context that YouTube does not have in quite the same form. Activity from people connected to you can create legitimate recommendation paths without requiring access to a private conversation.

So what feels like the app listening may actually be several weak signals lining up at the same time.

And from an engineering perspective, that is probably the more interesting explanation: a recommender can feel disturbingly specific without ever needing the signal you assumed it was using.


What this comparison teaches us about designing a recommender

Looking at Instagram and YouTube changed the way I think about recommendation systems.

The model matters, but several decisions around the model may matter even more.

Start with the objective, not the architecture

Before choosing embeddings, ANN indexes, or ranking models, decide what a successful recommendation actually means.

Is the goal:

  • immediate engagement?
  • completion rate?
  • long-term satisfaction?
  • discovery?
  • creator diversity?
  • retention?

Two systems can use almost identical architectures and still behave very differently because they optimize different outcomes.

A technically impressive ranker trained against the wrong objective will still produce the wrong product.

Model intent at more than one timescale

A user is not one static vector.

There is a difference between:

What I usually like
What I have cared about recently
What I want right now
Enter fullscreen mode Exit fullscreen mode

If the system ignores recent behavior, recommendations become stale.

If it reacts too aggressively, watching five Formula 1 clips could convince the system that Formula 1 has suddenly become your entire personality.

Good personalization needs some balance between persistent preference and temporary intent.

Candidate quality can matter as much as ranking quality

It is tempting to focus all the attention on the final neural ranker.

But if retrieval sends poor candidates downstream, the ranker cannot magically recover content that was never retrieved.

The Instagram duplicate-content example makes this especially clear.

Removing repeated copies, mixing candidate sources, preserving freshness, and exploring nearby interests can change the perceived quality of the feed before expensive ranking even begins.

Spend compute progressively

The recommendation funnel is also a useful general system-design pattern.

Use cheap operations while the search space is large. Spend expensive computation only after the candidate set becomes small enough to justify it.

And whenever possible, move stable work outside the request path.

That might mean precomputed embeddings, cached candidate information, or other offline computation that reduces what has to happen while the user is waiting.

Fast adaptation is a trade-off, not automatically a feature

This may be the most important lesson.

A system that changes immediately can feel remarkably intelligent.

It can also overfit to temporary behavior.

A system that changes slowly may feel less responsive, but it may preserve a better understanding of long-term interests.

So when building a recommender, the question is not just:

How quickly can the model learn what the user is doing?

It is also:

How quickly should the product allow that behavior to change what the user sees?

That decision sits somewhere between machine learning, system design, and product design.

And it may matter more than choosing the newest recommendation model.


So, was my original observation correct?

Partly.

Instagram really did feel more responsive to whatever I cared about in the moment, while YouTube Shorts often felt more anchored to creators, viewing history, and longer-term interests.

What changed after the research was my explanation for it.

I started with the assumption that Instagram simply had the better recommendation system. The evidence does not support that conclusion.

Both platforms use sophisticated multi-stage recommenders. The difference appears to come from how they combine recent behavior, historical interests, content relationships, and the objectives their ranking systems optimize.

Some of my original assumptions held up:

Assumption Table

But one important claim remains unproven: there is no public benchmark showing that Instagram Reels adapts faster than YouTube Shorts.

What we can say is more useful.

Instagram has documented mechanisms that can make changing interests highly visible, including fresh candidate sources, interest-based discovery, and duplicate handling. YouTube brings a broader history into the decision, including channels, search behavior, long-form consumption, and satisfaction signals.

So the difference I felt was probably not:

Instagram understands me better.

A better interpretation is:

The two systems appear to make different trade-offs between what matters to me right now and what has mattered to me over time.

That is a much more interesting engineering difference than declaring one algorithm the winner.

Blog by Naresh B. A.

Backend & AI Systems Engineer | Distributed Systems · Production ML

Portfolio: Naresh B A

Let’s connect on LinkedIn | GitHub: Naresh B A

Thanks for reading. This is my personal engineering perspective, and I’d genuinely be interested in hearing where you agree or disagree. ❤️

Top comments (0)