How do apps handle a million likes at once without crashing?

Nov 1, 2026 · updated Nov 1, 2026 · 6 min read

A famous creator posts a video. Within a minute, a million people tap the heart. Every tap has to be saved, counted and shown. So why doesn't the database fall over?

The short answer: big apps never let a million people write to the same place at the same time. They save each like quickly, count later, split the counter into many small counters, and show you a number from a cache. Let's walk through it step by step.

The problem: one "hot row"

The simplest design stores the like count in one column, for example posts.likes, and runs UPDATE posts SET likes = likes + 1 WHERE id = 42 for every tap. That works for a small app. With a million taps in a minute, every request fights for the same row. Databases protect a row with a lock while it is being changed, so the requests wait in line. Waiting requests hold connections, connections run out, and the whole app slows down, not only that post.

Engineers call this a hot row (or hot key). The fix is not a bigger database. The fix is to stop sending every tap to that one row.

Layer 1: save now, count later (a queue)

When you tap like, the app does the smallest possible thing: it records "user A liked post 42" as an event and puts it on a queue (systems such as Kafka, SQS or Redis Streams are common choices). That write is fast and does not lock the post row. Your app shows the heart as liked immediately.

A background worker reads events from the queue in batches, for example 500 at a time, and applies them together. One update of +500 is far cheaper than 500 separate updates. If the worker falls behind for a few seconds, nothing breaks: the events simply wait in the queue.

Layer 2: split one counter into many

Even batched, a single counter can become a hot spot for the most popular posts. So the count is split into several small counters, often called sharded counters. Each like is added to one of, say, 8 or 16 counters chosen at random. Writes spread out, so no single row takes all the load.

To show the total, the system adds the small counters together. That read is cheap because there are only a handful of them.

Layer 3: show the number from a cache

Reading the count is even more frequent than writing it, because everyone scrolling past the post sees it. So the number on your screen usually does not come straight from the database. It comes from a cache (an in-memory store such as Redis or Memcached) that holds a recent copy and is refreshed every few seconds.

This is why you sometimes see a like count jump, or even go down by one or two: you are looking at a slightly old copy, and the next refresh corrects it.

The rule behind it: fast and almost right

For a like counter, being exactly right every millisecond is not worth a slow or broken app. Nobody notices 1.20M versus 1.21M. This trade-off is called eventual consistency: the number becomes correct a little later, and the app stays fast. Money is different: a bank balance must be exact, so payments use stricter designs. Good system design is choosing the right trade-off for each kind of data.

Summary

• Problem: a million writes to one row cause lock waits, a "hot row".
• Queue: save the like as an event now, count in batches later.
• Sharded counters: spread writes over many small counters, sum on read.
• Cache: show a fast, slightly old copy; refresh every few seconds.
• Trade-off: eventual consistency for likes, strict consistency for money.

This is a simplified, general explanation of common patterns, not a description of any one company's private systems.

Written with AI assistance, then checked and edited by a human engineer. Found a mistake? Tell us.