🧮 Aptitude & Reasoning · Chapter 10

Estimation: order-of-magnitude answers

"How many events per second?" is not a trick question. It is a test of whether you can be roughly right in thirty seconds instead of precisely stuck.

Study this lesson free in the app →

The basics

Estimation (a Fermi estimate) is getting a number that is roughly right — within a factor of 2 or 3 — in under a minute, from things you can guess.

The problem it solves: in design rounds and in real planning you rarely have the exact figure, but you still have to decide. Is it 100 events a second (one Postgres is fine) or 100,000 (you need Kafka and partitions)? That decision only needs the order of magnitude, not the third decimal.

The mental model: break the unknown into a chain of guessable pieces — users × actions per user × bytes per action — round each one hard, multiply, and keep the units visible so they catch your mistakes. Then size for the peak, not the average.

Explained

"Roughly how much storage does a year of driver-location pings need?"

The wrong answer is "I'd need the exact ping rate". The right answer starts: "Let's say 50,000 active drivers, one ping every 5 seconds…" and lands within a factor of two, out loud, in under a minute.

Nobody is checking your arithmetic. They are checking whether you can make the unknown tractable.

The builder's glance

Ask an experienced builder how much concrete a patio needs and they look at it for three seconds and say "about two cubic metres".

They have not measured. They have a chain of anchors — a slab is roughly this thick, a metre square is roughly this much — and they multiply.

They are also never wildly wrong. Not 0.2, not 20. That is the actual skill: not accuracy, but staying inside the right order of magnitude. Being out by 20% costs nothing. Being out by 100× means you designed the wrong system.

The anchors worth memorising

Estimation is multiplication plus a handful of numbers you never have to look up.

TIME
  86,400 s in a day      ≈ 10^5    (a very useful rounding)
  2.6 million s in a month
  31.5 million s in a year ≈ 3×10^7

SIZE
  a small JSON event      ≈ 1 KB
  1 million × 1 KB        = 1 GB
  1 billion × 1 KB        = 1 TB
  Parquet vs raw JSON     ≈ 5-10× smaller

RATE
  1 per second            ≈ 86 K/day  ≈ 2.6 M/month
  100 per second          ≈ 8.6 M/day
  1,000 per second        ≈ 86 M/day  ≈ 31 B/year

SHAPE OF DEMAND
  peak ≈ 3-5× the average
  ~80% of traffic in ~30% of the hours

The single most valuable one: 1 per second is about 86,400 a day. Round it to 100,000 and almost every rate question becomes mental arithmetic.

Size it in sixty seconds

RideFlow operates in 12 Indian cities.

Estimate the storage for one year of raw driver-location pings, and the peak events per second.

Why interviewers keep asking this

Every system design round contains a sizing question, because the answer determines the architecture:

• 100 events/sec — a single Postgres and a cron job is genuinely fine. Proposing Kafka here is over-engineering, and saying so scores points
• 10,000 events/sec — now you need a log, partitioning, and a real ingestion path
• 1,000,000 events/sec — sampling, aggregation at the edge, and a serious conversation about what you are allowed to drop

Candidates who skip the estimate design for the wrong tier and cannot tell they have. The estimate is what makes "do we need Kafka?" answerable instead of a matter of taste.

And the follow-up is always about cost: 2 TB/year in cloud object storage is trivial money; 2 TB/year queried repeatedly in a warehouse is not. Storage is cheap, repeated compute is not — that sentence belongs in your answer.

1 per second ≈ 100,000 a day. A year ≈ 3×10⁷ seconds.

1 million KB = 1 GB. 1 billion KB = 1 TB.

Round to one significant figure, state every assumption, then multiply by a peak factor of 3–5.

Gotchas

• Refusing to guess. "I'd need real numbers" reads as an inability to reason under uncertainty — the exact skill being tested
• Precision theatre. 47,382 events/sec from guessed inputs is false confidence. Say "about 50,000"
• Sizing on the average. Systems fail at peak; always apply the factor
• Silent assumptions. If you don't say "assuming a ping every 5 seconds", a wrong answer looks like bad maths rather than a different assumption
• Forgetting compression and replication — they move the answer by 10× in opposite directions
• Losing track of units mid-chain. Write them down; units that cancel wrongly catch the error for you

The shape of a good answer

"How many events per second will this handle?"

"Let me size it. Assume 50,000 active drivers and a ping every 5 seconds — that's 10,000 a second if everyone's online, but realistically about a third are, so call it 3,000 average. Peak in the evening or in rain is maybe four times that, so I'd design for around 12,000 a second."

"At 200 bytes an event that's about 20 TB of raw a year, or 2 TB in compressed Parquet — cheap to keep. The write rate is well past what I'd want in an operational database, so this goes to Kafka and lands in object storage."

"I'd want to check the real ping interval and the concurrency ratio, because those two numbers move the answer most — but the architecture wouldn't change unless we're off by more than 10×."

The last sentence is what separates it: naming which assumption the answer is most sensitive to, and how wrong you'd have to be for the decision to flip.

Words to know

In two minutes

• Estimation means being within the right order of magnitude fast, not being precise.
• Write the target unit first, then break it into guessable factors: users × actions × size.
• Round every input to one significant figure, toward numbers you can multiply in your head.
• Key anchors: 1/sec ≈ 86,400/day ≈ 10⁵; a year ≈ 3×10⁷ seconds; 10⁹ × 1 KB = 1 TB.
• Systems fail at peak, so multiply the average by a peak factor of 3–5.
• State every assumption aloud and name the one the answer is most sensitive to.
• The estimate picks the architecture tier: 100/s, 10,000/s and 1,000,000/s are different systems.

Test yourself

There are 8 questions, 3 puzzles and 6 recall cards for this lesson in the app — the recall cards come back on later days, just before you would forget.