Back-of-Envelope Estimation — Series 2

Preview — 3 of 10 questions

An app has 50 million daily active users (DAU), and on average each user makes 20 requests per day, fairly evenly spread across a 24-hour period, except for a peak period where traffic runs at roughly 3x the average rate. What's the general approach to estimating peak QPS (queries per second) from these numbers?

APeak QPS is always identical to average QPS, since traffic is assumed to be perfectly uniform throughout the day in every system

BQPS estimation is purely theoretical and provides no useful guidance for actual infrastructure capacity planning

CPeak QPS estimation starts with total daily requests (DAU × requests/user = 50M × 20 = 1 billion), divides by seconds in a day (~86,400) to get the average QPS (~11,600), then multiplies by the peak factor (3x) to estimate peak QPS (~35,000) — because designing only for the average would leave the system unable to handle real traffic during the busiest period, which is exactly when capacity matters most

DPeak QPS is calculated by dividing total daily active users by the peak factor, with no reference to request counts at all

A chat app has 10 million daily active users, each sending an average of 40 messages per day, and each message averages 100 bytes (text only, no attachments). Roughly how would you estimate the daily storage growth from message text alone, and why is this a useful first estimate even though it's approximate?

AStorage estimation is impossible without exact message content, so no useful number can be derived from these averages at all

BDaily storage growth ≈ users × messages/user × bytes/message = 10M × 40 × 100 bytes = 40 billion bytes (~40 GB) per day for message text alone — this rough calculation is useful because it immediately reveals the order of magnitude (tens of GB/day, meaning terabytes/year), which is enough to start reasoning about database sizing, retention policy costs, and whether additional overhead (indexes, replication, metadata) will meaningfully multiply that baseline

CThe correct formula is to divide the number of users by the average message size, ignoring the number of messages sent entirely

DStorage estimation should only ever be done after the system is already built and storage costs are actually being paid, never beforehand

An initial estimate finds a social media feed system handles roughly 1,000 writes per second (new posts) but 100,000 reads per second (feed views) — a 100:1 read-to-write ratio. How should this specific ratio, once estimated, influence the system's architecture?

AA 100:1 read:write ratio means the system should be architected to optimize writes above all else, since writes are rarer and therefore more important

BThe read:write ratio has no bearing on architecture decisions — every system should be designed identically regardless of this ratio

CA 100:1 ratio indicates the system is fundamentally broken and the ratio should always be forced back to exactly 1:1 through artificial rate limiting

DA heavily read-skewed ratio like 100:1 points toward architecture decisions that optimize disproportionately for read performance — such as aggressive caching layers, multiple read replicas, and possibly precomputing/denormalizing feed data ahead of time (fan-out-on-write) — since the vast majority of load and user-facing latency comes from reads, while the comparatively rare writes can afford more processing overhead without hurting overall system responsiveness

Answer all 10 questions (7 more), see explanations for every answer, and track your score.