# How Celebrity Posts Go Viral Without Breaking Instagram - Source: https://intervueclub.com/blog/celebrity-posts-without-breaking-instagram - Author: Dhananjay Aggarwal - Published: 2026-01-01 - Tags: hot-keys, caching, scalability One post, millions of likes and comments in minutes. How Instagram handles the celebrity problem by keeping unbounded work off the synchronous path. When a celebrity posts on Instagram, the platform faces one of the harshest real-world load tests there is. Within minutes, a single post can attract: - millions of likes - millions of comments - millions of reads From a systems perspective, this is a nightmare scenario. One object suddenly becomes the hottest read key and the hottest write target in the entire system. If this traffic were handled like a normal post, the database would collapse almost instantly. In system design, this challenge is known as the **Celebrity Problem**. Instagram survives virality by **architecturally refusing to perform dangerous operations**, instead of scaling blindly. Let’s break down how. ![Dozens of phones, laptops and users all sending traffic to a single celebrity post with 4.2M likes, 1.8M comments and 10M views.](https://intervueclub.com/blog/celebrity-posts-without-breaking-instagram/2.webp) ## 1. The Celebrity Spike Problem Most backend systems are implicitly designed for evenly distributed traffic. Celebrity posts break that assumption immediately. A naive implementation would: - read millions of rows to display likes - synchronously insert millions of comment records - sort comments live on every request This leads to: - hot partitions - lock contention - cascading latency failures Instagram’s first architectural rule is strict: **No synchronous request may touch unbounded data.** If an operation can grow with popularity, it is pushed out of the critical path. ## 2. Likes Are Not Read as Rows When you see “4.2M likes”, Instagram is not querying 4.2 million records. Instead: - likes are modeled as **events**, not query results - each like action is written to write-optimized storage or logs - the displayed number comes from **cached aggregate counters** Key properties: - counters are eventually consistent - reads are constant-time - writes are append-only and cheap “4.2M likes” is a **materialized view**, not a live computation. ![Like events from phones flow into an async log, then an aggregation service, which updates a cached counter showing 4.2M likes.](https://intervueclub.com/blog/celebrity-posts-without-breaking-instagram/3.webp) ## 3. Comments Are Paginated and Sharded by Design Instagram never loads all comments for a post. Comments are: - partitioned by post\_id - distributed across independent shards - fetched in bounded windows Scrolling loads: - 20–50 comments at a time - already filtered and ranked There is no API that returns “all comments”. That endpoint does not exist. ## 4. Read Path and Write Path Are Fully Decoupled This is the most critical design decision. **Writes** (likes, comments): - flow through queues or append-only logs - are processed asynchronously - never block user-facing reads **Reads:** - hit caches and read replicas - fetch precomputed views - never wait on writes This separation means: - write spikes do not affect read latency - virality does not cascade into outages Reads and writes scale independently. ![On the write path, likes and comments go through a queue into counter and sharded comment datastores; on the read path, clients read from an LRU cache and a read replica.](https://intervueclub.com/blog/celebrity-posts-without-breaking-instagram/4.webp) ## 5. Multi-Layer Caching for Hot Posts Once a post starts going viral, it is quickly marked as **HOT**. Hot posts are served from: - CDN caches - edge caches - in-memory application caches As a result: - most requests never reach the database - recomputation is avoided - traffic is absorbed at the edge The database stays a system of record, not a traffic handler. ## 6. Ranking Is Precomputed, Not Sorted Live Instagram does not sort comments during user requests. Instead: - rankings are computed asynchronously - “top comments” are maintained with priority queues - updates are batched in the background When a user scrolls: - the backend fetches a prepared slice - returns it directly No live sorting. No expensive queries under load. ![A datastore splits comments into top, next and further buckets that are served to the post one page at a time.](https://intervueclub.com/blog/celebrity-posts-without-breaking-instagram/5.webp) ## 7. Async Fan-Out With Optimistic UI When you like or comment: - the UI updates instantly - the backend write happens asynchronously This is optimistic execution. The system assumes success and: - reconciles counters later - resolves conflicts asynchronously This avoids: - global locks - hot-row contention - user-visible latency spikes Correctness is eventual. Responsiveness is immediate. ## 8. Why Instagram Never “Fully Loads” Anything You never load: - all likes - all comments - all viewers Everything is: - paginated - windowed - eventually consistent Unbounded operations are explicitly forbidden on the synchronous path. This is not an optimization. It is a survival strategy. ## Final Takeaway **Instagram scales viral posts by refusing to read or write unbounded data synchronously.** Virality does not break the system because the system was designed on the assumption that virality would happen. That is real-world system design.