Hide outline
Feedback
Guide
Was this lesson helpful?
Dive Deeper
Generate a follow-up sub-lesson on any aspect of this topic
Guide complete
Napkin Math Capacity Estimation
Generate a follow-up sub-lesson on any aspect of this topic
Napkin Math Capacity Estimation
TLDR;
- A defensible peak QPS for feed reads drops out once sessions, actions, and peak factor are explicit.
- A 30 day hot storage number becomes stable when you bake in index and replication multipliers early.
- Peak egress usually dominates first, and one assumption change can flip the whole design constraint set.
Sizing a social feed service starts with naming the three numbers that will shape every early architecture sketch. peak read QPS, hot storage, and peak network egress. For one region with 2M daily active users and a 150ms end to end budget, the first design meeting needs estimates that are directionally right and unit consistent, even if they are not yet precise. The goal is to pick components that have headroom under peak, not to win accuracy points on the first pass. Let’s anchor on a baseline feed read path so we can hang the math on real boxes.
In that baseline, clients hit stateless API servers behind a load balancer, the API path reads from a cache first, and falls back to a database on a cache miss. The 150ms budget is shared across network hops, queueing, cache or database work, and serialization. That means capacity is not only about average throughput. It is also about keeping queues short at peak so tail latency does not eat the budget.
A napkin estimate stays useful when it uses a few constants and rounds consistently. Write conversions once, then reuse them, because most interview errors come from mixing per day and per second, or bytes and bits, in the middle of a derivation. The following reference card is the minimum set that keeps estimates stable as you vary assumptions. Take a quick scan before we start computing.
If we stick to one rounding rule, the numbers stay comparable across QPS, storage, and bandwidth. For example, treating makes quick division easier, while treating makes memory sizing tighter. Either is fine as long as we do not mix them inside the same calculation, and we always convert to bits when we talk about network links.
Rule of thumb
Keep one unit in the numerator and one in the denominator at every step, or stop and fix it.
Peak QPS is not a DAU number, it is a behavior number, so the key design idea is to expose the behavioral knobs. We assume a user opens the app a certain number of sessions per day, triggers a certain number of feed loads per session, and the system experiences a peak factor where traffic spikes above average. Once those are written down, QPS is just dividing by seconds per day and multiplying by peak factor. The feed read path is the one to size first because it typically dominates requests. The next widget computes this with explicit unit cancellation.
After you pick inputs, the calculation is the same shape every time. Average QPS is , and peak QPS is that average multiplied by the peak factor. The important consequence is architectural. If peak QPS lands in the tens of thousands, a single database primary is unlikely to survive without heavy caching and partitioning. If peak QPS is only in the low hundreds, the design pressure shifts away from throughput and toward correctness and latency.
The fastest way to avoid building on bad math is to treat every result as guilty until it passes two checks. First, dimensional analysis asks whether the units reduce to what we claimed, like requests per second or bytes per day. Second, order of magnitude bounding asks whether the number is even plausible for 2M DAU, given that only a fraction of users are active in any given second. These checks are what stop a stray factor of 8, 1000, or 86400 from snowballing into a wrong architecture choice. Use the checkpoint below to practice spotting the failure mode, not just the wrong number.
The patterns are consistent across mistakes. If a QPS number looks like millions for this scenario, the derivation often forgot to divide by 86400, or treated DAU as concurrent users. If a bandwidth number looks tiny but QPS is large, the payload was probably in bytes while the link was sized in bits per second. Training this reflex matters in interviews because a clean correction with a clear unit fix reads as engineering judgment, not as guessing.
Hot storage sizing starts with the records you must serve fast, then adds the overhead that real systems pay. For a feed, that means post content and media pointers, per post metadata, and the indexing structures that let the database answer queries quickly. On top of that, replication multiplies bytes because you keep multiple copies for availability and maintenance. A practical mental model is that stored bytes equal raw record size times record count times an overhead multiplier that covers indexes and replication. Let’s estimate 30 day hot storage first, then contrast it with long term storage growth.
What usually surprises people is how quickly overhead dominates. If the raw post row is small but you maintain secondary indexes for author_id, created_at, or feed precompute tables, the index bytes can be comparable to the data bytes. Replication then multiplies it again, so a replication factor turns a 1 TB raw estimate into 3 TB before indexes, and potentially 6 TB or more after indexing. This is why hot retention is a first class knob. If the system can serve older content from colder storage with higher latency, the hot tier footprint and cost drop dramatically.
Caveat
If the feed is fanout on write, the per follower edge storage can dwarf post storage.
Network sizing ties request rate to response size, and it fails loudly when payload assumptions are sloppy. For feed reads, egress is usually the dominant direction because responses include many items, thumbnails, and metadata, while writes are small and less frequent. The core equation is peak egress peak QPS payload bytes per response, converted to bits per second. Compression, CDN caching, and cache hit rate change the payload and the origin request rate, so the right move is to show how sensitive peak Gbps is to those knobs. Adjust them below and watch which one moves the needle most.
After tuning, read the peak egress in the same units your network team speaks, typically Gbps at the service edge or at the origin. If compression shrinks a 200KB response to 40KB, the bandwidth drops by without changing QPS. If a CDN serves most media and even some API responses, origin egress may fall sharply while client egress stays the same. This distinction matters in design discussions because it changes whether you buy bigger links, add more cache, or move content closer to users.
Napkin math breaks when one hidden multiplier dominates, so the key idea is to name the few assumption changes that flip which dimension is binding. A higher peak factor increases QPS and bandwidth but not storage. Larger payloads increase bandwidth without changing QPS. Higher replication multiplies storage and some write bandwidth. Multiple regions multiply the whole footprint unless you can localize reads and avoid cross region writes. Toggle the changes below and watch which of QPS, storage, or bandwidth becomes the first order constraint.
When one toggle makes a metric jump, it is a signal to revisit the architecture, not to argue about the last digit. A peak factor shift from to can turn a comfortable cache into a thundering herd on the database. A payload jump from 20KB to 200KB can move the bottleneck from CPU to NIC and force aggressive response trimming. A replication increase can turn a single cluster into a sharded fleet just to keep storage and compaction manageable. These are the moments to ask what changed in product behavior or SLOs, because the system is responding rationally to the new constraint.
For the 2M DAU single region feed, the defensible output of this exercise is not one perfect estimate, it is three peak numbers with stated assumptions. peak feed read QPS sized from sessions, actions, and peak factor, 30 day hot storage sized from record bytes times volume times overhead, and peak egress sized from QPS times payload with a clear bits conversion. With those on the table, you can argue about design choices like cache tiers, database partitioning, and CDN placement using the same shared frame.
The closing move in an interview is to ask which assumption is most uncertain and most expensive if wrong. If the answer is peak factor, you push for instrumentation and throttling plans. If it is payload size, you push for response budgets and progressive loading. If it is retention or replication, you push for tiering and lifecycle policies. Napkin math works because it makes that uncertainty visible early, and that is what prevents a feed service from being fast at average and broken at peak.