A team sizes storage for a new event log - 40 million events a day at about 1.2 KB each kept for 5 years - computes 87 TB and proposes a tiered data lake. Daily volume has grown roughly 60% a year for three years. Review the estimate. Which error most changes the number?

What is being tested

Whether you check an estimate's dominant term before checking its details. Every option here is a real error. Only one moves the answer by more than 3x, and finding it is a two-minute calculation that most reviewers skip in favour of arguing about the per-event size.

The arithmetic

The team's number is right for their assumption: 40e6 x 1.2 KB = 48 GB a day, x 365 x 5 = 87.6 TB.

Now apply the growth they already measured. Year one is 48 GB/day x 365 = 17.5 TB, and each later year multiplies by 1.6:

17.5 + 28.0 + 44.8 + 71.7 + 114.7 = 276.7 TB

The five-year total is about 280 TB, not 87 TB - a factor of 3.2. And the exit rate matters more than the total: by year five the log ingests 154 GB a day, three times what the design was sized for. A compound term is invisible in a spreadsheet that multiplies today's rate by a retention window, which is exactly why this error survives review.

Why the other options fail

• Record size drift. Genuinely happens; fields get added and nobody removes any. But it is bounded and slow - 1.2 KB becoming 1.5 KB is 1.25x, and you would notice it in the data before it hurt. Worth a sentence in the assumptions, not a redesign.
• Replication and compression. The right instinct and the two effects pull against each other. Three-way replication multiplies by 3; columnar compression on repetitive JSON-shaped events commonly divides by 5 to 10. The product is usually below 1x, so the omission flatters the estimate in a direction that does not threaten the design. Compute it, then move on.
• Retention of seven years instead of five. With flat volume that is 1.4x. With the growth term it is worse - but the growth term is already the thing you fixed, and a retention change is a known future event you can plan for rather than a hidden error in today's number.

What a strong review adds

Restate the estimate as a range with its driver named. "280 TB at the observed 60% growth; 87 TB only if growth stops; 500 TB if it reaches 80%." Then name the one measurement that narrows it: the month-over-month ingest rate for the last 18 months, which tells you whether 60% is still the current rate or an artefact of a launch.

Then say what the number changes. At 87 TB the question is which storage tier. At 280 TB with a 154 GB/day exit rate, the partitioning scheme, the compaction schedule and the query engine are all in scope - and a decision about them is much harder to reverse later than a storage-tier choice.

When this is the wrong answer

When the growth is known to be a one-off. If the 60% came from onboarding a large customer segment that is now fully onboarded, extrapolating it is the error. The test is whether the growth mechanism still has room to run: more users, more events per user, or more event types. If none of the three can grow, flat is the right assumption and the per-event size becomes the dominant term after all.