Imagine it's 19th November 2023.
India has just won the Cricket World Cup.
Virat Kohli uploads a celebration post.
Within minutes...
500K Likes
↓
2 Million Likes
↓
10 Million Likes
↓
25+ Million LikesMillions of people are refreshing Instagram simultaneously.
Everyone wants to:
- View the post
- Like it
- Comment
- Share it
- Open Virat's profile
Now imagine Instagram stores posts in MySQL.
Every refresh executes:
SELECT *
FROM posts
WHERE id = 123;Every like executes:
UPDATE posts
SET likes = likes + 1With millions of users...
The database would collapse within seconds.
So how does Instagram survive?
The Naive Architecture
Users
↓
Load Balancer
↓
Backend
↓
MySQLSimple.
Until Virat posts.
Instead of hundreds of requests...
Instagram suddenly receives:
3 Million Requests / MinuteOne database cannot handle that amount of traffic.
The problem isn't storage.
It's reads.
Most Requests Are Reads
Think about what people actually do.
Open Profile
View Post
Refresh Feed
Open CommentsAlmost nobody creates content.
Millions simply read it.
A celebrity post may receive:
Reads
25 Million
Writes
25 Million LikesReads massively outnumber writes.
Optimizing reads becomes the priority.
Enter Redis
Instead of fetching the post from MySQL every time...
Instagram first checks Redis.
User
↓
Backend
↓
RedisIf the post exists...
The response is returned in a few milliseconds.
MySQL is never touched.
Only when Redis misses does Instagram query the database.
Redis Miss
↓
MySQL
↓
Redis Cache
↓
UserMost requests never reach MySQL.
But Even Redis Has Problems
Imagine 20 million people requesting the exact same key.
post:virat-worldcupThis becomes a Hot Key.
One Redis node suddenly receives enormous traffic.
Large systems distribute hot data across multiple cache nodes and replicate popular content to avoid overloading a single machine.
Caching solves many problems...
But celebrity traffic creates new ones.
Likes Are Even Harder
Suppose two million users press Like within one second.
Should Instagram execute:
UPDATE posts
SET likes = likes + 1two million times?
No.
The database would spend all its time updating one row.
Instead...
Likes are first collected in memory.
Like
↓
Redis CounterRedis performs atomic increments.
25,000,001
↓
25,000,002
↓
25,000,003The database is updated asynchronously every few seconds.
This dramatically reduces write load.
But Doesn't That Mean The Count Is Wrong?
Yes.
And that's perfectly acceptable.
Suppose Redis currently says:
24,983,211 LikesMySQL still says:
24,981,904 LikesFor a few seconds...
Those numbers differ.
Nobody cares.
A small delay is invisible to users.
Availability matters more than absolute accuracy here.
This is a classic example of eventual consistency.
What About Notifications?
Suppose 25 million people like Virat's post.
Should Instagram immediately send:
25 Million NotificationsAbsolutely not.
Virat's phone would explode.
Instead...
Notification services batch and aggregate events.
Rather than sending:
John liked your post.
Sarah liked your post.
Mike liked your post.Instagram combines them into:
John and 99 others liked your post.Much cheaper.
Much cleaner.
Serving Images
The biggest file isn't the database record.
It's the image.
If every user downloaded it from Instagram's servers...
Bandwidth costs would be enormous.
Instead...
Images are cached worldwide using a CDN.
User (India)
↓
Nearest CDN
↓
ImageThe image rarely reaches Instagram's origin servers.
Edge locations serve most requests.
This keeps latency low and infrastructure costs manageable.
Building Feeds
Now imagine everyone following Virat refreshes their home feed.
Should Instagram calculate every user's feed on demand?
Not for celebrities.
Instead...
Many social platforms precompute or cache feeds for highly followed accounts, while using different strategies for ordinary users.
This hybrid approach balances freshness with scalability.
Follow-Up Questions Interviewers Love
Why cache posts but not passwords?
Posts are public and frequently read.
Passwords are sensitive and should never be cached in plaintext.
Why is eventual consistency acceptable for likes?
Seeing 25,000,001 instead of 25,000,005 for a few seconds doesn't affect the user experience.
Blocking the app while waiting for perfect consistency would.
Why not update MySQL on every like?
Millions of writes to the same row create contention and drastically reduce throughput.
Buffering writes through Redis is far more efficient.
Why use a CDN?
Without one, every image request would hit Instagram's servers directly, creating unnecessary bandwidth costs and latency.
Lessons Beyond Instagram
The same architecture appears everywhere.
- YouTube view counts.
- LinkedIn reactions.
- Reddit upvotes.
- Facebook likes.
- X reposts.
- GitHub stars.
Different products.
The same scaling challenges.
Final Thoughts
When Virat Kohli posts, Instagram isn't solving one problem.
It's solving thousands simultaneously.
Caching hot content.
Handling millions of concurrent reads.
Aggregating likes.
Batching notifications.
Serving media through CDNs.
Accepting eventual consistency where users won't notice.
The biggest lesson isn't about Redis or MySQL.
It's understanding that not every number needs to be perfectly accurate in real time.
Sometimes, being off by a few likes for a few seconds is a small price to pay for keeping Instagram online while millions of fans celebrate the same moment.